On 15/01/17 20:20, Euler Taveira wrote: > On 15-01-2017 15:13, Petr Jelinek wrote: >> I am not quite sure I agree with this. Either it's system object and we >> don't replicate it (which I would have considered to be anything with >> Oid < FirstNormalObjectId) or it's user made and then it should be >> replicated. Filtering by schema name is IMHO way too fragile (what stops >> user creating additional tables there for example). >> > What happens if you replicate information_schema tables? AFAICS, those > tables are already in the subscriber database. And will it generate > error or warning? (I'm not sure how this functionality deals with > schemas.) Also, why do I want to replicate a information schema table? > Their contents are static and, by default, it is already in each database. > > Information schema isn't a catalog but I think it is good to exclude it > from FOR ALL TABLES clause because the use case is almost zero. Of > course, it should be documented. Also, if someone wants to replicate an > information schema table, it could do it with ALTER PUBLICATION. >
Well the preinstalled information_schema is excluded by the FirstNormalObjectId filter as it's created by initdb. If user drops and recreates it that means it was created as user object. My opinion is that FOR ALL TABLES should replicate all user tables (ie, anything that has Oid >= FirstNormalObjectId), if those are added to information_schema that's up to user. We also replicate user created tables in pg_catalog even if it's system catalog so I don't see why information_schema should be filtered on schema level. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
