Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
От | Gilles Darold |
---|---|
Тема | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column |
Дата | |
Msg-id | f1e1ba3e-3592-baf9-8bce-88cac8ce29b2@migops.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Le 14/10/2021 à 20:26, Tom Lane a écrit : > "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. I not agree, expansion in executed when there is no column list provided and this affect SELECT and INSERT. It cover the same needs: being able to remove a column for the target list when it is not explicitly set. This feature is known like this and I'm not in favor to tear off a leg. -- Gilles Darold
В списке pgsql-hackers по дате отправления: