Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: Gilles Darold <gilles(at)migops(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Date: 2021-10-15 08:37:37
Message-ID: CAJ7c6TNo5W2SuQ-VkejjSXZxPx0TMTiCubBD5i-VbcBZxoN6ng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Gilles,

> I can turn the column hidden and I will not have to modify my old very
good application.

I see your point. At the same time, I believe the statement above shows the
root reason why we have a different view on this feature. The application
should have never use SELECT * in the first place. This is a terrible
design - you add a column or change their order and the application is
broken. And I don't believe the DBMS core is the right place for placing
hacks for applications like this. This should be solved in the application
itself or in some sort of proxy server between the application and DBMS.
SELECT * is intended to be used by people e.g. DBA.

> Also as Vik or Dave mention being able to hide all tsvector columns from
query without
> having to specify it as exception in each query used can save some time.

Agree, this sometimes can be inconvenient. But I don't think there are many
cases when you have a table with tens of columns you want to hide. SELECT *
EXCEPT should work just fine for 1 or 2 columns. For other cases, you can
simply create a VIEW.

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2021-10-15 08:38:31 Re: Multi-Column List Partitioning
Previous Message Julien Rouhaud 2021-10-15 08:35:25 Re: installcheck fails when compute_query_id=on or pg_stat_statsement is loaded