On Friday, October 6, 2023, Tom Lane <t...@sss.pgh.pa.us> wrote: > "David G. Johnston" <david.g.johns...@gmail.com> writes: > >> On 10/6/23 08:45, Ron wrote: > >>> 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". > > > 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. > > Changing the default behavior now is certainly a non-starter. > I don't really see any backwards-compatibility problem with > allowing cases that had been errors, though. >
I wouldn’t vote against it but the current simplicity seems sufficient. “Copy table doesn’t recognize generated columns, use copy (select) if you want to include them in the output.” David J.
