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
signature.asc
Description: PGP signature
