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

On 10/6/23 11:08, David G. Johnston wrote:
> 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.

At least it's explicitly mentioned in the docs that generated columns are
excluded.

>
> The error message maybe could use some help though, and if there isn't a
> hint maybe add one.
>
> David J.
>

--
Born in Arizona, moved to Babylonia.