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

From Josef Šimánek
Subject Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Date
Msg-id CAFp7QwpUhq=rkmYcVMVx4xCybSgGOn63EPb_5S0j+ACjwFO9zw@mail.gmail.com
Whole thread Raw
In response to [PATCH] Proposal for HIDDEN/INVISIBLE column  (Gilles Darold <gilles@migops.com>)
Responses Re: [PATCH] Proposal for HIDDEN/INVISIBLE column  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-hackers
čt 14. 10. 2021 v 13:17 odesílatel Gilles Darold <gilles@migops.com> napsal:
>
> Hi,
>
>
> Here is a proposal to implement HIDDEN columns feature in PostgreSQL.
>
> The user defined columns are always visible in the PostgreSQL. If user
> wants to hide some column(s) from a SELECT * returned values then the
> hidden columns feature is useful. Hidden column can always be used and
> returned by explicitly referring it in the query.
>
> I agree that views are done for that or that using a SELECT * is a bad
> practice
> but sometime we could need to "technically" prevent some columns to be part
> of a star expansion and nbot be forced to use view+rules.

Just to remind here, there was recently a proposal to handle this
problem another way - provide a list of columns to skip for "star
selection" aka "SELECT * EXCEPT col1...".

https://postgrespro.com/list/id/d51371a2-f221-1cf3-4a7d-b2242d4dafdb@gmail.com

> For example when
> upgrading a database schema where a column have been added to a table,
> this will break any old version of the application that is using a
> SELECT * on
> this table. Being able to "hide" this column to such query will make
> migration
> easier.
>
> An other common use case for this feature is to implements temporal tables
> or row versionning. On my side I see a direct interest in Oracle to
> PostgreSQL
> migration to emulate the ROWID system column without the hassle of creating
> views, it will save lot of time.
>
> The other advantage over views is that the hidden column can still be used
> in JOIN, WHERE, ORDER BY or GROUP BY clause which is not possible otherwise.
> I don't talk about writing to complex view which would require a RULE.
>
> Hidden column is not part of the SQL standard but is implemented in all
> other
> RDBMS which is also called invisible columns [1] [2] [3] [4]. In all
> these RDBMS
> the feature is quite the same.
>
>    [1] https://www.ibm.com/docs/en/db2/10.5?topic=concepts-hidden-columns
>    [2] https://oracle-base.com/articles/12c/invisible-columns-12cr1
>    [3]
> https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql?view=sql-server-ver15
>    [4] https://dev.mysql.com/doc/refman/8.0/en/invisible-columns.html
>
>
> Here is the full description of the proposal with a patch attached that
> implements
> the feature:
>
>    1) Creating hidden columns:
>
>       A column visibility attribute is added to the column definition
>       of CREATE TABLE and ALTER TABLE statements. For example:
>
>           CREATE TABLE htest1 (a bigserial HIDDEN, b text);
>
>           ALTER TABLE htest1 ADD COLUMN c integer HIDDEN;
>
>       Columns are visible by default.
>
>    2) Altering column visibility attribute:
>
>       The ALTER TABLE statement can be used to change hidden columns to not
>       hidden and the opposite. Example:
>
>           ALTER TABLE htest1 ALTER COLUMN c DROP HIDDEN;
>
>    3) Insert and hidden columns:
>
>       If the column list of INSERT or COPY statements is empty
>       then while expanding column list hidden columns are NOT
>       included. DEFAULT or NULL values are inserted for hidden
>       columns in this case. Hidden column should be explicitly
>       referenced in the column list of INSERT and COPY statement
>       to insert a value.
>
>       Example:
>
>         -- Value 'one' is stored in column b and 1 in hidden column.
>         INSERT INTO t1 VALUES ('one');
>
>         -- Value 2 is stored in hidden column and 'two' in b.
>         INSERT INTO htest1 (a, b) VALUES (2, 'two');
>
>    4) Star expansion for SELECT * statements:
>
>       Hidden columns are not included in a column list while
>       expanding wild card '*' in the SELECT statement.
>
>       Example:
>
>           SELECT * FROM htest1;
>             b
>           ------
>            one
>            two
>
>        Hidden columns are accessible when explicitly referenced
>        in the query.
>
>        Example:
>           SELECT f1, f2 FROM t1;
>              a  |  b
>           ------+------
>             1   | one
>             2   | two
>
>    5) psql extended describe lists hidden columns.
>
>        postgres=# \d+ htest1
>                                        Table "public.htest1"
>         Column |  Type  | Collation | Nullable |  Default   | Visible | ...
> --------+--------+-----------+----------+------------+---------+ ...
>         a      | bigint |           | not null | nextval... | hidden  | ...
>         b      | text   |           |          | |         | ...
>
>    6) When a column is flagged as hidden the attishidden column value of
>       table pg_attribute is set to true.
>
>    7) For hidden attributes, column is_hidden of table
> information_schema.columns
>       is set to YES. By default the column is visible and the value is 'NO'.
>
> For a complete description of the feature, see chapter "Hidden columns" in
> file doc/src/sgml/ddl.sgml after applying the patch.
>
>
> The patch is a full implementation of this feture except that I sill have to
> prevent a ALTER ... SET HIDDEN to be applied of there is no more visible
> columns in the table after the change. I will do that when I will recover
> more time.
>
> I have choose HIDDEN vs INVISIBLE but this could be a minor change or
> we could use NOT EXPANDABLE. Personnaly I prefer the HIDDEN attribute.
>
>
> Any though and interest in this feature?
>
> --
> Gilles Darold
> http://www.migops.com/
>



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?
Next
From: Isaac Morland
Date:
Subject: Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?