From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Subject: | Re: why can't a table be part of the same publication as its schema |
Date: | 2022-09-20 09:27:03 |
Message-ID: | 20220920092703.rypusmjsw4ihw6ap@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-Sep-20, Amit Kapila wrote:
> On Mon, Sep 19, 2022 at 8:46 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Zhang Mingli | 2022-09-20 09:37:32 | Re: Add 64-bit XIDs into PostgreSQL 15 |
Previous Message | Justin Pryzby | 2022-09-20 09:26:43 | Re: Add 64-bit XIDs into PostgreSQL 15 |