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: >>> Here is a proposal to implement HIDDEN columns feature in PostgreSQL.
>> Another use case I can think of is not covered in this patch, but it >> could be (I hope!) or even if not I would like opinions on this idea. >> What about a boolean GUC log_hidden_column that throws a LOG message when >> a hidden column is used directly? > 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. If you are trying to figure out whether you have any applications that depend on column X (without breaking anything), you should absolutely not start by marking the column "hidden", because that'll break the case where the apps are expecting "SELECT *" to return the column. But if you're okay with breaking things, you might as well just drop the column, or else revoke SELECT privilege on it, and see what happens. I'm not sure about the utility of logging explicit references to a specific column --- seems like grepping the results of "log_statement" would serve. But in any case I think it is not a good idea to tie it to this proposal. 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. I also do not care for the syntax you propose: AFAICS the only reason you've gotten away with making HIDDEN not fully reserved is that you require it to be the last attribute of a column, which is something that will trip users up all the time. Plus, it does not scale to the next thing we might want to add. So if you can't make it a regular, position-independent element of the ColQualList you shouldn't do it at all. 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. BTW, you do NOT get to add an information_schema column for this. The information_schema is defined in the SQL standard. Yes, I'm aware that mysql feels free to "extend" the standard in that area; but our policy is that the only point of having the information_schema views at all is if they're standard-compliant. regards, tom lane