pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: why can't a table be part of the same publication as its schema
Date: Tue, 20 Sep 2022 11:27:03 +0200
Message-ID: <20220920092703.rypusmjsw4ihw6ap@alvherre.pgsql> (raw)
In-Reply-To: <CAA4eK1+rTRuZ9P=XDuYJbb-c8YBCZ0=zESdX6hxRY8dKByTE2A@mail.gmail.com>

On 2022-Sep-20, Amit Kapila wrote:

> On Mon, Sep 19, 2022 at 8:46 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> > This seems a pretty arbitrary restriction.  It feels like you're adding
> > this restriction precisely so that you don't have to write the code to
> > reject the ALTER .. SET SCHEMA if an incompatible configuration is
> > detected.  But we already have such checks in several cases, so I don't
> > see why this one does not seem a good idea.
> >
> I agree that we have such checks at other places as well and one
> somewhat similar is in ATPrepChangePersistence().
> 
> ATPrepChangePersistence()
> {
> ...
> ...
> /*
>      * Check that the table is not part of any publication when changing to
>      * UNLOGGED, as UNLOGGED tables can't be published.
>      */

Right, I think this is a sensible approach.

> However, another angle to look at it is that we try to avoid adding
> restrictions in other DDL commands for defined publications.

Well, it makes sense to avoid restrictions wherever possible.  But here,
the consequence is that you end up with a restriction in the publication
definition that is not very sensible.  Imagine if you said "you can't
add schema S because it contains an unlogged table".  It's absurd.

Maybe this can be relaxed in a future release, but it's quite odd.

> The intention was to be in sync with FOR ALL TABLES.

I guess we can change both (FOR ALL TABLES and IN SCHEMA) later.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/





view thread (46+ messages)  latest in thread

Message-ID: <20220920092703.rypusmjsw4ihw6ap@alvherre.pgsql>
Permalink:  ../20220920092703.rypusmjsw4ihw6ap@alvherre.pgsql/
Also on:    postgresql.org/message-id/20220920092703.rypusmjsw4ihw6ap@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, amit.kapila16@gmail.com, houzj.fnst@fujitsu.com, vignesh21@gmail.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com
  Subject: Re: why can't a table be part of the same publication as its schema
  In-Reply-To: <20220920092703.rypusmjsw4ihw6ap@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