Re: why generated columsn cannot be used in COPY TO? - Mailing list pgsql-general

From David G. Johnston
Subject Re: why generated columsn cannot be used in COPY TO?
Date
Msg-id CAKFQuwYPL5bvL=HviP715JqBAUBTmxwATBRLKNZUeMqg5NiTEA@mail.gmail.com
Whole thread Raw
In response to Re: why generated columsn cannot be used in COPY TO?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Friday, October 6, 2023, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@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.
 

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: why generated columsn cannot be used in COPY TO?
Next
From: Bruce Momjian
Date:
Subject: Re: Gradual migration from integer to bigint?