| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: why generated columsn cannot be used in COPY TO? |
| Date: | 2023-10-06 16:37:25 |
| Message-ID: | 2970696.1696610245@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2023-10-06 20:16:28 | Re: Restoring default privileges on objects |
| Previous Message | Ron | 2023-10-06 16:17:38 | Re: why generated columsn cannot be used in COPY TO? |