Re: Weird behaviour with the new MOVE clause of ALTER TABLESPACE

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Weird behaviour with the new MOVE clause of ALTER TABLESPACE
Дата
Msg-id 20140509211648.GQ2556@tamriel.snowman.net
обсуждение исходный текст
Ответ на Weird behaviour with the new MOVE clause of ALTER TABLESPACE  (Guillaume Lelarge <guillaume@lelarge.info>)
Ответы Re: Weird behaviour with the new MOVE clause of ALTER TABLESPACE
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg_class.relpages/allvisible probably shouldn't be a int4
Следующее
От: Tom Lane
Дата:
Сообщение: Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)