Re: why generated columsn cannot be used in COPY TO?
От | Tom Lane |
---|---|
Тема | Re: why generated columsn cannot be used in COPY TO? |
Дата | |
Msg-id | 2970696.1696610245@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: why generated columsn cannot be used in COPY TO? ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: why generated columsn cannot be used in COPY TO?
|
Список | pgsql-general |
"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. regards, tom lane
В списке pgsql-general по дате отправления: