Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
От | Gilles Darold |
---|---|
Тема | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column |
Дата | |
Msg-id | f38b5fb6-3004-f182-979a-e6c6610769e7@migops.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: