Re: RFC: Moving specific attributes from pg_attribute column into attoptions - Mailing list pgsql-hackers

Nikita Malakhov <hukutoc@gmail.com> writes:
> We already had some thoughts on storing, let's call them "optional"
> attributes into 'attoptions' instead of extending the PG_ATTRIBUTE
> table, and here came feedback from Andres Freund with a remark that
> we're increasing the largest catalog table. So we decided to propose
> moving these "optional" attributes from being the PG_ATTRIBUTE column to
> be the part of 'attoptions' column of this table.

This smells very much like what was done eons ago to create the
pg_attrdef catalog.  I don't have any concrete comments to make,
only to suggest that that's an instructive parallel case.  One
thing that comes to mind immediately is whether this stuff could
be unified with pg_attrdef instead of creating Yet Another catalog
that has to be consulted on the way to getting any real work done.

I think that pg_attrdef was originally separated to keep large
default expressions from overrunning the maximum tuple size,
a motivation that disappeared once we could TOAST system tables.
However, nowadays it's still useful for it to be separate because
it simplifies representation of dependencies of default expressions
(pg_depend refers to OIDs of pg_attrdef entries for that).
If we're thinking of moving anything that would need dependency
management then it might need its own catalog, maybe?

On the whole I'm not convinced that what you suggest will be a
net win.  pg_attrdef wins to the extent that there are a lot of
columns with no non-null default and hence no need for any pg_attrdef
entry.  But the minute you move something that most tables need, like
attcompression, you'll just have another bloated catalog to deal with.

> Also, we suggest that options stored in 'attoptions' column could be packed
> as JSON values.

Please, no.  Use of JSON in a SQL database pretty much always
represents a failure to think hard enough about what you need
to store.  Sometimes it's not worth thinking all that hard;
but I strenuously oppose applying that sort of standard in
the system catalogs.

                        regards, tom lane