Re: Weird behaviour with the new MOVE clause of ALTER TABLESPACE - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Weird behaviour with the new MOVE clause of ALTER TABLESPACE
Date
Msg-id 20140509211648.GQ2556@tamriel.snowman.net
Whole thread Raw
In response to Weird behaviour with the new MOVE clause of ALTER TABLESPACE  (Guillaume Lelarge <guillaume@lelarge.info>)
Responses Re: Weird behaviour with the new MOVE clause of ALTER TABLESPACE  (Guillaume Lelarge <guillaume@lelarge.info>)
List pgsql-hackers
Guillaume,

* Guillaume Lelarge (guillaume@lelarge.info) wrote:
> Should information_schema tables be moved and not pg_catalog ones? it
> doesn't seem consistent to me.

The catalog tables are moved by changing the database's tablespace, eg:

ALTER DATABASE ... SET TABLESPACE

That also moves any objects which are not assigned to a specific
tablespace.

The question ends up being just which side of "is it part of the
catalog, or not?" the information schema falls on to.  For this case, I
had considered those to *not* be part of the catalog as they can be
moved independently of the ALTER DATABASE ... SET TABLESPACE.

This is happily documented:
  System catalogs will not be moved by this command- individuals wishing to  move a whole database should use ALTER
DATABASE,or call ALTER TABLE on the  individual system catalogs.  Note that relations in
<literal>information_schema</literal> will be moved, just as any other normal database objects, if the user is the
superuseror considered an owner of the relations in <literal>information_schema</literal>.
 
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_class.relpages/allvisible probably shouldn't be a int4
Next
From: Tom Lane
Date:
Subject: Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)