Re: [HACKERS] generated columns

On Tue, Oct 30, 2018 at 4:35 AM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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