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