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

From Aleksander Alekseev
Subject Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Date
Msg-id CAJ7c6TNo5W2SuQ-VkejjSXZxPx0TMTiCubBD5i-VbcBZxoN6ng@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Proposal for HIDDEN/INVISIBLE column  (Gilles Darold <gilles@migops.com>)
Responses Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
List 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

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: installcheck fails when compute_query_id=on or pg_stat_statsement is loaded
Next
From: Amit Langote
Date:
Subject: Re: Multi-Column List Partitioning