Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Дата
Msg-id 894844.1634235983@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] Proposal for HIDDEN/INVISIBLE column  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: [PATCH] Proposal for HIDDEN/INVISIBLE column  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCH] Proposal for HIDDEN/INVISIBLE column  (Gilles Darold <gilles@migops.com>)
Список pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> Taking this a bit further, I dislike tying the suppression of the column
> from the select-list star to the behavior of insert without a column list
> provided.  I’m not fully on board with having an attribute that is not
> fundamental to the data model but rather an instruction about how that
> column interacts with SQL; separating the two aspects, though, would help.
> I accept the desire to avoid star expansion much more than default columns
> for insert.

Yeah, me too.  I think it would add a lot of clarity if we defined this
as "this affects the behavior of SELECT * and nothing else" ... although
even then, there are squishy questions about how much it affects the
behavior of composite datums that are using the column's rowtype.
But as soon as you want it to bleed into INSERT, you start having a
lot of questions about what else it should bleed into, as Aleksander
already mentioned.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?
Следующее
От: Gilles Darold
Дата:
Сообщение: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column