On 10/30/18, Peter Eisentraut <peter.eisentr...@2ndquadrant.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
