On Thursday, October 14, 2021, Tom Lane <t...@sss.pgh.pa.us> wrote: > Gilles Darold <gil...@migops.com> writes: > > Le 14/10/2021 à 17:38, Jaime Casanova a écrit : > >> On Thu, Oct 14, 2021 at 01:16:45PM +0200, Gilles Darold wrote: > > > Why not, I will add it if there is a consencus about logging hidden > > column use, this is not a big work. > > This seems like a completely orthogonal idea.
> +1 > As for the proposal itself, I'm kind of allergic to the terminology > you've suggested, because the column is in no way hidden. It's > still visible in the catalogs, you can still select it explicitly, > etc. Anybody who thinks this is useful from a security standpoint > is mistaken, but these words suggest that it is. Perhaps some > terminology like "not expanded" or "unexpanded" would serve better > to indicate that "SELECT *" doesn't expand to include the column. > Or STAR versus NO STAR, maybe. 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. Especially since the most compelling example of the later, not having to specify generated columns on insert, would directly conflict with the fact that it is those generated columns that are most likely to be useful to display when specifying a star in the select query. > What I think is actually important is the ALTER COLUMN syntax. > We could easily get away with having that be the only syntax for > this --- compare the precedent of ALTER COLUMN SET STATISTICS. +1 > > BTW, you do NOT get to add an information_schema column for > this. FWIW, +1, though the project policy reminder does stand on its own. David J.
