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

2014-05-10 Thread Stephen Frost
* Guillaume Lelarge (guilla...@lelarge.info) wrote: > Thanks for the explanation. I should have RTFM before complaining. Sorry > for the noise :) No prob. If people don't feel that makes sense then we can still change it.. I don't feel particularly strongly either way, though I seem to recall my

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

2014-05-10 Thread Guillaume Lelarge
On Fri, 2014-05-09 at 17:16 -0400, Stephen Frost wrote: > Guillaume, > > * Guillaume Lelarge (guilla...@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 tab

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

2014-05-09 Thread Stephen Frost
Guillaume, * Guillaume Lelarge (guilla...@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 o

[HACKERS] Weird behaviour with the new MOVE clause of ALTER TABLESPACE

2014-05-09 Thread Guillaume Lelarge
Hey, I was working on adding support to the new MOVE clause of the ALTER TABLESPACE statement to pgAdmin when I noticed this issue. See this example: Fresh git compilation, and new database on a new cluster: $ createdb b1 $ psql b1 psql (9.4devel) Type "help" for help. b1=# CREATE TABLESPACE ts