Re: ALTER TABLE on system catalogs

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-09-28T19:15:03Z
Lists: pgsql-hackers
On 2018-09-28 16:06:30 -0300, Alvaro Herrera wrote:
> On 2018-Aug-21, Andres Freund wrote:
> 
> > On 2018-08-21 17:04:41 +0200, Peter Eisentraut wrote:
> >
> > > That doesn't solve the original problem, which is being able to set
> > > reloptions on pg_attribute, because pg_attribute doesn't have a toast
> > > table but would need one according to existing rules.
> > 
> > I still think it's wrong to work around this than to actually fix the
> > issue with pg_attribute not having a toast table.
> 
> FWIW I'm still bothered by the inability to move pg_largeobject to a
> different tablespace, per
> https://postgr.es/m/20160502163033.GA15384@alvherre.pgsql
> While that needs even more work (preservability across pg_dump for one),
> this item here would be one thing to fix.
> 
> Also, I don't quite understand what's so horrible about setting
> autovacuum options for system catalogs, including those that don't have
> toast tables.  That seems a pretty general feature that needs fixing,
> too.

I'm not sure what that has to do with my point?  What I'm saying is that
we shouldn't have some weird "should have a toast table but doesn't"
exception, not that we shouldn't allow any sort of DDL on catalogs.


Greetings,

Andres Freund


Commits

  1. Ignore attempts to add TOAST table to shared or catalog tables