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

From Tom Lane
Subject Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Date
Msg-id 894844.1634235983@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Proposal for HIDDEN/INVISIBLE column  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> Taking this a bit further, I dislike tying the suppression of the column
> from the select-list star to the behavior of insert without a column list
> provided.  I’m not fully on board with having an attribute that is not
> fundamental to the data model but rather an instruction about how that
> column interacts with SQL; separating the two aspects, though, would help.
> I accept the desire to avoid star expansion much more than default columns
> for insert.

Yeah, me too.  I think it would add a lot of clarity if we defined this
as "this affects the behavior of SELECT * and nothing else" ... although
even then, there are squishy questions about how much it affects the
behavior of composite datums that are using the column's rowtype.
But as soon as you want it to bleed into INSERT, you start having a
lot of questions about what else it should bleed into, as Aleksander
already mentioned.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?
Next
From: Gilles Darold
Date:
Subject: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column