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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: why generated columsn cannot be used in COPY TO?
Дата
Msg-id CAKFQuwY2j=P50HpXwB-KpZZN3J-71bt18U0zirjOADpBezVSWw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: why generated columsn cannot be used in COPY TO?  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: why generated columsn cannot be used in COPY TO?
Re: why generated columsn cannot be used in COPY TO?
Список pgsql-general
On Fri, Oct 6, 2023 at 8:54 AM Adrian Klaver <adrian.klaver@aklaver.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.

В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: why generated columsn cannot be used in COPY TO?
Следующее
От: Ron
Дата:
Сообщение: Re: why generated columsn cannot be used in COPY TO?