Re: missing toast table for pg_policy

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-02-17 11:39:57 -0500, Tom Lane wrote:
>> pg_aggregate | agginitval | text
>> pg_aggregate | aggminitval | text

> Seems like it should have a toast table, it's not too hard to imagine
> some form of aggregate to have a large initial condition.

Really? I should think the initial condition would almost always be some
spelling of "zero". Certainly nobody's ever complained of this in the
past.

>> pg_attribute | attacl | aclitem[]
>> pg_attribute | attfdwoptions | text[]
>> pg_attribute | attoptions | text[]

> Seems like it should have a toast table, but I think other people
> differed.

I think there was fear of circularity if we tried to toast pg_class
or pg_attribute. (In particular, VACUUM FULL already has its hands
full handling pg_class correctly --- dealing with a toast table too
would probably be really, uh, interesting.) Also, given the fact
that tupdescs can only store the fixed-width part of a pg_attribute
entry, having var-width fields in there at all is a pretty dubious
decision; it's way too easy to forget about that and try to fetch
them out of a tupdesc entry. I think the right approach for
potentially-long per-attribute properties is exemplified by pg_attrdef.

In any case, I don't see any of the "options" columns as things that
are likely to get long enough to be a problem. ACLs maybe could get
long, but I can only recall perhaps one thread complaining about that,
so I don't feel that there's field demand to justify toasting all the
catalogs with ACLs in them.

>> pg_largeobject | data | bytea

> We deal with this in other ways.

Right, this is one that definitely should not have a toast table.

>> pg_partitioned_table | partexprs | pg_node_tree

> Probably makes sense.

Dunno, what is a sane partitioning expression?

I don't feel that we need to insist on having a toast table for every
theoretically toastable column. The point here is to make a conscious
decision for each such column that we don't expect it to get long.
I think most of these columns are probably fine. Unsure about the
partitioning-related ones.

regards, tom lane