Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

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

In response to

Browse pgsql-hackers by date

  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