From: | John Naylor <jcnaylor(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] generated columns |
Date: | 2018-11-01 09:46:31 |
Message-ID: | CAJVSVGVKb8BdkiXQidYHUY7jfWKF_Jrqh86MBTLLwOG2jx8HcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/30/18, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> 3. Radical alternative: Collapse everything into one new column. We
> could combine atthasdef and attgenerated and even attidentity into a new
> column. (Only one of the three can be the case.) This would give
> client code a clean break, which may or may not be good. The
> implementation would be uglier than #1 but probably cleaner than #2. We
> could also get 4 bytes back per pg_attribute row.
Thinking about the distinction between 'stored' and 'virtual', I
immediately thought of atthasmissing. In a way it indicates that there
is a virtual default value. It seems the level of materialization is
an orthogonal concept to the kind of value we have. What if
attgenerated had
d = normal default value
i = identity default
a = identity always
c = generated column
and in addition there was an attmaterialized column with
s = stored
v = virtual
In this scheme,
-Normal attribute: '\0' + 's'
-Default value: 'd' + 's'
-Fast default: 'd' + 'v' until the table is rewritten
-Identity column: 'i'/'a' + 's'
-Generated column: 'c' + 's'/'v'
This way, we'd still end up with 1 fewer column (2 new ones minus
atthasdef, attidentity, and atthasmissing).
A bit crazier, what if "d = dropped" was another allowed value in
attmaterialized -- we could then get rid of attisdropped as well. That
has obvious disadvantages, but the broader idea is that this design
may have use cases we haven't thought of yet.
Thoughts?
-John Naylor
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2018-11-01 10:27:00 | Re: pg_promote not marked as parallel-restricted in pg_proc.dat |
Previous Message | Tomas Vondra | 2018-11-01 09:44:32 | Re: Super PathKeys (Allowing sort order through precision loss functions) |