Gilles Darold <gilles@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
