Hi hackers! Tom, thank you for your feedback! We thought about this because it already seems that custom Toasters could have a bunch of options, so we already thinking how to store them.
I'll check if we can implement storing Toaster options in PG_ATTRDEF. Andres Freund complained that 'atttoaster' column extends already the largest catalog table. It is a reasonable complain because atttoaster option only makes sense for columns and datatypes only, and the Default Toaster is accessible by global constant DEFAULT_TOASTER_OID and does not require accessing the PG_ATTRDEF table. Also, we thought about making Toaster responsible for column compression and thus moving 'attcompression' out from PG_ATTRIBUTE column to Toaster options. What do you think about this? Using JSON - accepted, we won't do it. On Wed, Aug 17, 2022 at 11:51 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Nikita Malakhov <huku...@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 > -- Regards, Nikita Malakhov https://postgrespro.ru/
