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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: houzj(dot)fnst(at)fujitsu(dot)com, mark(dot)dilger(at)enterprisedb(dot)com, amit(dot)kapila16(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, peter(dot)eisentraut(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org, robertmhaas(at)gmail(dot)com
Subject: Re: why can't a table be part of the same publication as its schema
Date: 2022-09-20 14:01:19
Message-ID: 20220920140119.mct473wrvvrikrg2@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2022-Sep-13, Kyotaro Horiguchi wrote:

> At Mon, 12 Sep 2022 04:26:48 +0000, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com> wrote in

> > I feel we'd better compare the syntax with the existing publication command:
> > FOR ALL TABLES. If you create a publication FOR ALL TABLES, it means publishing
> > all the tables in the database *including* tables created in the future. I
> > think both the syntax and meaning of ALL TABLES IN SCHEMA are consistent with
> > the existing FOR ALL TABLES.
>
> IMHO, I feel closer to Robert. "ALL TABLES IN SCHEMA" sounds like the
> concrete tables at the time of invocation. While I agree that it is
> not directly comparable to GRANT,

What if we remove the ALL keyword from there? That would leave us with
"FOR TABLES IN SCHEMA", which seems to better convey that it doesn't
restrict to current tables in there.

> but if I see "ALTER PUBLICATION p1 ADD SCHEMA s1", I automatically
> translate that into "all tables in the schema s1 at the time of using
> this publication".

... but that translation is wrong if replication supports other kinds of
objects, as it inevitably will in the near future. Clearly the fact
that we spell out TABLES there is important. When we add support for
sequences, we could have combinations

ADD [ALL] TABLES IN SCHEMA s
ADD [ALL] SEQUENCES IN SCHEMA s
ADD [ALL] TABLES AND SEQUENCES IN SCHEMA s

and at that point, the unadorned ADD SCHEMA one will become ambiguous.

> At least, it would cause less confusion when it were "ALT PUB p1 DROP
> SCEMA s1" aginst "DROP ALL TABLES IN SCHEMA s1".

I'm not sure what you mean here.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"En las profundidades de nuestro inconsciente hay una obsesiva necesidad
de un universo lógico y coherente. Pero el universo real se halla siempre
un paso más allá de la lógica" (Irulan)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2022-09-20 14:10:22 Re: On login trigger: take three
Previous Message Sergey Shinderuk 2022-09-20 13:43:59 Re: On login trigger: take three