Re: [HACKERS] generated columns
От | Erik Rijkers |
---|---|
Тема | Re: [HACKERS] generated columns |
Дата | |
Msg-id | d87903a2723f6e31c15e4a90ba681a75@xs4all.nl обсуждение исходный текст |
Ответ на | Re: [HACKERS] generated columns (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] generated columns
|
Список | pgsql-hackers |
On 2019-04-02 14:43, Peter Eisentraut wrote: > On 2019-04-01 10:52, Peter Eisentraut wrote: >> On 2019-03-31 05:49, Erik Rijkers wrote: >>> STORED in a >>> file_fdw foreign table still silently creates the column which then >>> turns out to be useless on SELECT, with an error like: >>> >>> "ERROR: column some_column_name is a generated column >>> DETAIL: Generated columns cannot be used in COPY." >>> >>> Maybe it'd be possible to get an error earlier, i.e., while trying to >>> create such a useless column? >> >> I'll look into it. > > I've been trying to create a test case for file_fdw for this, but I'm > not getting your result. Can you send a complete test case? Ah, I had not noticed before: with an asterisk ('select * from table' ) one gets no error, just empty values. An actual error seems to occur when one mentions the generated-column-name explicitly in the select-list. select "id", "Ratio Log2 GEN" from <file_fdw foreign table>; " ERROR: column "Ratio Log2 GEN" is a generated column DETAIL: Generated columns cannot be used in COPY. " That's from a quick test here at work; maybe that gives you enough info. If that doesn't make it repeatable (for you) I'll make a more complete example this evening (from home).
В списке pgsql-hackers по дате отправления: