From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Gilles Darold <gilles(at)migops(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column |
Date: | 2021-10-14 18:26:23 |
Message-ID: | 894844.1634235983@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gilles Darold | 2021-10-14 18:26:39 | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column |
Previous Message | Robert Haas | 2021-10-14 18:22:04 | Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function? |