Re: why can't a table be part of the same publication as its schema - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: why can't a table be part of the same publication as its schema
Date
Msg-id CAA4eK1Kkx7WDi0aTz6rdE-VbWmzxHcRFGYnyv36gqQaMmEvMhA@mail.gmail.com
Whole thread Raw
In response to Re: why can't a table be part of the same publication as its schema  ("Jonathan S. Katz" <jkatz@postgresql.org>)
List pgsql-hackers
On Wed, Sep 21, 2022 at 1:15 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> (RMT hat on, unless otherwise noted)
>
> On 9/20/22 9:42 AM, Robert Haas wrote:
> > On Mon, Sep 19, 2022 at 11:03 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> >> For #1 (allowing calls that have schema/table overlap...), there appears
> >> to be both a patch that allows this (reversing[8]), and a suggestion for
> >> dealing with a corner-case that is reasonable, i.e. disallowing adding
> >> schemas to a publication when specifying column-lists. Do we think we
> >> can have consensus on this prior to the RC1 freeze?
> >
> > I am not sure whether we can or should rush a fix in that fast, but I
> > agree with this direction.
>
> The RMT met today to discuss this.
>
> We did agree that the above is an open item that should be resolved
> before this release. While it is an accepted pattern for us to "ERROR"
> on unsupported behavior and then later introduce said behavior, we do
> agree with Peter's original post in this thread and would like it resolved.
>

As there seems to be an agreement with this direction, I think it is
better to commit the patch in this release (before RC1) to avoid users
seeing any behavior change in a later release. If the proposed
behavior for one of the cases (disallowing adding schemas to a
publication when specifying column-lists) turns out to be too
restrictive for users, we can make it less restrictive in a future
release. I am planning to commit the current patch [1] tomorrow unless
RMT or anyone else thinks otherwise.

[1] -
https://www.postgresql.org/message-id/OS0PR01MB57162E862758402F978725CD944B9%40OS0PR01MB5716.jpnprd01.prod.outlook.com

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Making C function declaration parameter names consistent with corresponding definition names
Next
From: Bharath Rupireddy
Date:
Subject: Re: binary version of pg_current_wal_insert_lsn and pg_walfile_name functions