Re: missing toast table for pg_policy

On 2018-07-20 08:46:50 +0900, Michael Paquier wrote:
> On Thu, Jul 19, 2018 at 07:18:32PM -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> >> FWIW, I was off the last few days. I personally think the reasoning to
> >> leave out pg_class, pg_index etc. is bad. We should just make them work
> >> and create toast tables as well.
> >
> > If it's easy to make those work and keep them working, then sure, but
> > I have my doubts. I remain afraid of circular accesses occurring only
> > in strange corner cases ...
>
> I have found the argument about circular dependencies rather sensible
> FWIW. So at the end it seems to me that we would not want to add toast
> tables for those catalogs.

As argued a fair bit ago, I think that isn't actually an issue: As long
as we keep the boostrap relevant fields from being toasted, there's no
issue with circularlity. Given the initial contents are defined to be
static or live in relmapper there's no danger of that accidentally
happening.

> >> It's definitely not right that "those
> >> relations have no reason to use a toast table anyway." as the commit
> >> message states, given relacl, reloptions and relpartbound.
> >
> > I wonder whether we shouldn't have handled ACLs through something more
> > like the pg_description solution, ie keep them all in one catalog with
> > a (classoid, objoid) primary key.
>
> That could be nice, but separate from the fact of adding a toast table
> to it?

Yea, that seems mostly independent.

Greetings,

Andres Freund