Re: [HACKERS] generated columns

On Tue, Oct 30, 2018 at 09:35:18AM +0100, Peter Eisentraut 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".
>
> 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.
>
> 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.

#3 looks very appealing in my opinion as those columns have no overlap,
so it would take five possible values:
- generated always
- generated by default
- default value
- stored expression
- virtual expression

Obviously this requires a first patch to combine the catalog
representation of the existing columns atthasdef and attidentity.

+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("generated colums are not supported
on typed tables")));
s/colums/columns/.
--
Michael