RE: why can't a table be part of the same publication as its schema

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

In response to

Responses

Browse pgsql-hackers by date

  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