From: | Gilles Darold <gilles(at)migops(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column |
Date: | 2021-10-14 18:26:39 |
Message-ID: | f38b5fb6-3004-f182-979a-e6c6610769e7@migops.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-10-14 18:43:41 | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column |
Previous Message | Tom Lane | 2021-10-14 18:26:23 | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column |