Re: why generated columsn cannot be used in COPY TO?

On Fri, Oct 6, 2023 at 8:54 AM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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.