Re: [PATCH] Proposal for HIDDEN/INVISIBLE column - Mailing list pgsql-hackers

From Gilles Darold
Subject Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Date
Msg-id f38b5fb6-3004-f182-979a-e6c6610769e7@migops.com
Whole thread Raw
In response to Re: [PATCH] Proposal for HIDDEN/INVISIBLE column  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Le 14/10/2021 à 19:44, Tom Lane a écrit :
> 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.


Agree, I also had this feeling. I decide to use HIDDEN like in DB2 just 
because UNEXPANDED looks to me difficult to understand by users and that 
hidden or Invisible column are well known. This is a kind of "vendor 
standard" now. But I agree that it can confuse uninformed people and 
doesn't reflect the real feature. I will rename the keyword as 
"UNEXPANDED", will do.


> 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.


Yes I have also noted that and wanted to improve this later if the 
proposal was accepted.


> 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.


Ok great, I'm fine with that, especially for the previous point :-) I 
will remove it from the CREATE TABLE syntax except in the INCLUDING like 
option.


> 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.

Ok, I will remove it.


-- 
Gilles Darold




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column