From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Weird behaviour with the new MOVE clause of ALTER TABLESPACE |
Date: | 2014-05-09 21:16:48 |
Message-ID: | 20140509211648.GQ2556@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Guillaume,
* Guillaume Lelarge (guillaume(at)lelarge(dot)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
superuser or considered an owner of the relations in <literal>information_schema</literal>.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-05-09 21:22:03 | Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?) |
Previous Message | Andres Freund | 2014-05-09 20:50:24 | Re: pg_class.relpages/allvisible probably shouldn't be a int4 |