Re: why can't a table be part of the same publication as its schema - Mailing list pgsql-hackers

From Robert Haas
Subject Re: why can't a table be part of the same publication as its schema
Date
Msg-id CA+TgmoZOE9uDzjiLBi_8yqVcqrfMYfvp02DLF1fFzOR9Zp4txg@mail.gmail.com
Whole thread Raw
In response to Re: why can't a table be part of the same publication as its schema  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: why can't a table be part of the same publication as its schema
List pgsql-hackers
On Fri, Sep 9, 2022 at 5:21 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> So, why shouldn't a "FOR ALL TABLES IN SCHEMA" publication follow a
> similar behavior?

Surely that is not the same case at all. If you're publishing
everything, there's no point in also having a specific list of things
that you want published, but when you're publishing only some things,
there is. If my wife tells me to wash everything in the laundry basket
and also my nice pants, and I discover that my nice pants already
happen to be in the laundry basket, I do not tell her:

ERROR:  my nice pants are already in the laundry basket

It feels like a mistake to me that there's any catalog representation
at all for a table that is published because it is part of a schema.
The way a feature like this should work is that the schema should be
labelled as published, and we should discover which tables are part of
it at any given time as we go. We shouldn't need separate catalog
entries for each table in the schema just because the schema is
published. But if we do have such catalog entries, surely there should
be a difference between the catalog entry that gets created when the
table is individually published and the one that gets created when the
containing schema is published. We have such tracking in other cases
(coninhcount, conislocal; attinhcount, attislocal).

In my opinion, this shouldn't have been committed working the way it does.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Avoid overhead with fprintf related functions
Next
From: Himanshu Upadhyaya
Date:
Subject: Re: HOT chain validation in verify_heapam()