Hi, On 2019-05-09 09:30:50 +0200, Peter Eisentraut wrote: > On 2019-05-09 04:37, Tom Lane wrote: > > I'm of two minds what to do about that. One approach is to just > > define a "FOR ALL TABLES" publication as including the information_schema > > tables, > > certainly not
Yea, that strikes me as a bad idea too. > It would also make sense to integrate both of these concepts more > consistently with the user_catalog_table feature. Perhaps the > information_schema tables could be made user catalogs. Really we should > just have a single flag in pg_class that says "I'm a catalog", > applicable both to built-in catalogs and to user-defined catalogs. Hm - I'm not convinced by that. There's some lower-level reasons why we can't easily replicate changes to system catalogs, but those don't exist for user catalog tables. And in fact, they can be replicated today. > I think we can get rid of the ability to reload the information_schema > after initdb. That was interesting in the early phase of its > development, but now it just creates complications. Yea, I'm far from convinced it's worth having that available. I wonder if we at least could have the reordering instructions not drop information_schema, so we'd have a stable oid for that. Or use some pg_upgrade style logic to recreate it. Or have NamespaceCreate() just hardcode the relevant oid for information_schema. Greetings, Andres Freund
