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 99dba6e0-a1ac-4ad8-7ca0-06cc4efa2e77@migops.com
Whole thread Raw
In response to Re: [PATCH] Proposal for HIDDEN/INVISIBLE column  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Le 14/10/2021 à 13:47, Aleksander Alekseev a écrit :
> Hi Gilles,
>
>> Any though and interest in this feature?
> Personally, I wouldn't call this feature particularly useful. `SELECT
> *` is intended for people who are working with DBMS directly e.g. via
> psql and want to see ALL columns. The applications should never use
> `SELECT *`. So I can't see any real benefits of adding this feature to
> PostgreSQL. It will only make the existing code and the existing user
> interface even more complicated than they are now.


Thanks for your comments Aleksander. This was also my thougth at 
begining but unfortunately there is cases where things are not so simple 
and just relying on SELECT * is dirty or forbidden.  The hidden column 
are not only useful for SELECT * but also for INSERT without column 
list, but INSERT without column list is also a bad practice.


> Also, every yet another feature is x N corner cases when this feature
> works with other N features of PostgreSQL. How should it work with
> partitioned or inherited tables? Or with logical replication? With
> pg_dump? With COPY?


I recommand you to have look to my patch because the partitioned and 
inherited case are covered, you can have a . For logical replication I 
guess that any change in pg_attribute is also replicated so I I would 
said that it is fully supported. But obviously I may miss something. 
pg_dump and COPY are also supported.


Actually the patch only prevent an hidden column to be part of a star 
expansion for the returned column, I don't think there is corner case 
with the other part of the code outside that we need to prevent a table 
to have all columns hidden. But I could miss something, I agree.


> So all in all, -1. This being said, I very much appreciate your
> attempt to improve PostgreSQL. However next time before writing the
> code I suggest submitting an RFC first.


Don't worry about my time spent for the PG community, this patch is a 
dust in my contribution to open source :-) If I have provided the patch 
to show the concept and how it can be easily implemented.  Also it can 
be used in some PostgreSQL forks if one is interested by this feature.


-- 

Gilles Darold




pgsql-hackers by date:

Previous
From: Amul Sul
Date:
Subject: Re: prevent immature WAL streaming
Next
From: Robert Haas
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname