pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: houzj.fnst@fujitsu.com
Cc: mark.dilger@enterprisedb.com
Cc: amit.kapila16@gmail.com
Cc: tgl@sss.pgh.pa.us
Cc: peter.eisentraut@enterprisedb.com
Cc: pgsql-hackers@postgresql.org
Cc: robertmhaas@gmail.com
Subject: Re: why can't a table be part of the same publication as its schema
Date: Tue, 20 Sep 2022 16:01:19 +0200
Message-ID: <20220920140119.mct473wrvvrikrg2@alvherre.pgsql> (raw)
In-Reply-To: <20220913.134023.460492970872809991.horikyota.ntt@gmail.com>

On 2022-Sep-13, Kyotaro Horiguchi wrote:

> At Mon, 12 Sep 2022 04:26:48 +0000, "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.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)





view thread (46+ messages)  latest in thread

Message-ID: <20220920140119.mct473wrvvrikrg2@alvherre.pgsql>
Permalink:  ../20220920140119.mct473wrvvrikrg2@alvherre.pgsql/
Also on:    postgresql.org/message-id/20220920140119.mct473wrvvrikrg2@alvherre.pgsql

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: alvherre@alvh.no-ip.org, horikyota.ntt@gmail.com, houzj.fnst@fujitsu.com, mark.dilger@enterprisedb.com, amit.kapila16@gmail.com, tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, robertmhaas@gmail.com
  Subject: Re: why can't a table be part of the same publication as its schema
  In-Reply-To: <20220920140119.mct473wrvvrikrg2@alvherre.pgsql>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox