Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Gilles DAROLD <gilles@darold.net>

From: Gilles Darold <gilles@darold.net>
To: Pavel Stehule <pavel.stehule@gmail.com>, Vik Fearing <vik@postgresfriends.org>
Cc: Aleksander Alekseev <aleksander@timescale.com>, Gilles Darold <gilles@migops.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-10-14T13:32:00Z
Lists: pgsql-hackers
Le 14/10/2021 à 14:28, Pavel Stehule a écrit :
>
>
> čt 14. 10. 2021 v 14:13 odesílatel Vik Fearing 
> <vik@postgresfriends.org <mailto:vik@postgresfriends.org>> napsal:
>
>     On 10/14/21 1:47 PM, Aleksander Alekseev wrote:
>     > 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.
>
>     I disagree strongly with this.  It is really annoying when working
>     interactively with psql on a table that has a PostGIS geometry column,
>     or any other large blobby type column.
>
>     I have not looked at the patch, but +1 for the feature.
>
>
> Cannot be better to redefine some strategies for output for some types.
>
> I can agree so sometimes in some environments proposed features can be 
> nice, but it can be a strong footgun too.
>
> Maybe some strange data can be filtered in psql and it can be better 
> solution. I agree, so usually print long geometry in psql is useless.


Pavel this doesn't concern only output but input too, think about the 
INSERT or COPY without a column list. We can add such filter in psql but 
how about other clients? They all have to implement their own filtering 
method. I think the HIDDEN attribute provide a common and basic way to 
implement that in all client application.


-- 
Gilles Darold
http://www.darold.net/