On Fri, Oct 6, 2023 at 8:54 AM Adrian Klaver <adrian.kla...@aklaver.com> wrote:
> On 10/6/23 08:45, Ron wrote: > > On 10/6/23 09:04, Andreas Kretschmer wrote: > >> > > >>> Not sure how convincing that reasoning is, but it was at least > >>> thought about. I do agree with it as far as the default column > >>> list goes, but maybe we could allow explicit selection of these > >>> columns in COPY TO. > >> > >> sounds okay > > > > Nah. "The programmer -- and DBA -- on the Clapham omnibus" quite > > reasonably expects that COPY table_name TO (output)" copies all the > > columns listed in "\d table_name". > > > > Yeah, I would agree. > > Sure, but it doesn't. Mainly since copy's original design was intended to solve the dump/restore problem and it doesn't make sense to specify data for inbound generated data. So while we do have a POLA violation here the desirability to now fix it years later is basically zero. And the current behavior is at least defensible and consistent. And there is a very easy way to get the desired output making any change that much harder a sell. The error message maybe could use some help though, and if there isn't a hint maybe add one. David J.
