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/