Re: [HACKERS] generated columns - Mailing list pgsql-hackers

On Tue, Oct 30, 2018 at 4:35 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> 1. (current implementation) New column attgenerated contains 's' for
> STORED, 'v' for VIRTUAL, '\0' for nothing.  atthasdef means "there is
> something in pg_attrdef for this column".  So a generated column would
> have atthasdef = true, and attgenerated = s/v.  A traditional default
> would have atthasdef = true and attgenerated = '\0'.  The advantage is
> that this is easiest to implement and the internal representation is the
> most useful and straightforward.  The disadvantage is that old client
> code that wants to detect whether a column has a default would need to
> be changed (otherwise it would interpret a generated column as having a
> default value instead).
>
> 2. Alternative: A generated column has attgenerated = s/v but atthasdef
> = false, so that atthasdef means specifically "column has a default".
> Then a column would have a pg_attrdef entry for either attgenerated !=
> '\0' or atthasdef = true.  (Both couldn't be the case at the same time.)
>  The advantage is that client code wouldn't need to be changed.  But
> it's also possible that there is client code that just does a left join
> of pg_attribute and pg_attrdef without looking at atthasdef, so that
> would still be broken.  The disadvantage is that the internal
> implementation would get considerably ugly.  Most notably, the tuple
> descriptor would probably still look like #1, so there would have to be
> a conversion somewhere between variant #1 and #2.  Or we'd have to
> duplicate all the tuple descriptor access code to keep that separate.
> There would be a lot of redundancy.
>
> 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.
>
> I'm happy with the current choice #1, but it's worth thinking about.

I don't have a strong position on 1 vs. 2 vs. 3, but I do think it
would be nicer not to use '\0' as a column value.  I'd suggest you use
'n' or '0' or '-' or some other printable character instead.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company