From: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: why can't a table be part of the same publication as its schema |
Date: | 2022-09-09 14:29:37 |
Message-ID: | OS0PR01MB5716FA725E51EF7F130E59AC94439@OS0PR01MB5716.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday, September 9, 2022 9:57 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Sep 9, 2022 at 5:21 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > So, why shouldn't a "FOR ALL TABLES IN SCHEMA" publication follow a
> > similar behavior?
Hi
>
> 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.
IIRC, the feature currently works almost the same as you described. It doesn't
create entry for tables that are published via its schema level, it only record
the published schema and check which tables are part of it.
Sorry, If I misunderstand your points or missed something.
Best regards,
Hou zj
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-09-09 14:31:10 | Re: Introduce wait_for_subscription_sync for TAP tests |
Previous Message | Alvaro Herrera | 2022-09-09 14:20:50 | Re: [PATCH v1] fix potential memory leak in untransformRelOptions |