Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
От | Gilles Darold |
---|---|
Тема | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column |
Дата | |
Msg-id | 99dba6e0-a1ac-4ad8-7ca0-06cc4efa2e77@migops.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column (Aleksander Alekseev <aleksander@timescale.com>) |
Список | 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 по дате отправления: