Re: Fuzzy thinking in is_publishable_class

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