On Thu, Oct 14, 2021 at 2:32 PM Gilles Darold <gil...@darold.net> wrote:
> Le 14/10/2021 à 14:28, Pavel Stehule a écrit : > > > > čt 14. 10. 2021 v 14:13 odesílatel Vik Fearing <v...@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. > I like the idea - being able to hide computed columns such as tsvectors from CRUD queries by default seems like it would be very nice for example. -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com
