From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Amit Kapila <amit.kapila16@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>, houzj.fnst@fujitsu.com,
        Tomas Vondra <tomas.vondra@enterprisedb.com>,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: bogus: logical replication rows/cols combinations
In-reply-to: <20220519120724.GO19626@telsasoft.com>
References: 
 <CAA4eK1+UCfKUaf41H6zHS2qR4CZoVtZe64yx_T-JVPSb1pdw_w@mail.gmail.com>
 <202205161320.butjtubabvgj@alvherre.pgsql>
 <CAA4eK1KfL=ez5fKPB-0Nrgf7wiqN9bXP-YHHj2YH5utXAmjYug@mail.gmail.com>
 <20220519120724.GO19626@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Thu, 19 May 2022 07:07:24 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <165763.1652970286.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 May 2022 10:24:46 -0400
Message-ID: <165764.1652970286@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/165764.1652970286%40sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> On Thu, May 19, 2022 at 10:33:13AM +0530, Amit Kapila wrote:
>> I have committed the first patch after fixing this part. It seems Tom
>> is not very happy doing this after beta-1 [1]. The reason we get this
>> information via this view (and underlying function) is that it
>> simplifies the queries on the subscriber-side as you can see in the
>> second patch. The query change is as below:
>> [1] - https://www.postgresql.org/message-id/91075.1652929852%40sss.pgh.=
pa.us

> I think Tom's concern is that adding information to a view seems like ad=
ding a
> feature that hadn't previously been contemplated.
> (Catalog changes themselves are not prohibited during the beta period).

It certainly smells like a new feature, but my concern was more around the
post-beta catalog change.  We do those only if really forced to, and the
explanation in the commit message didn't satisfy me as to why it was
necessary.  This explanation isn't much better --- if we're trying to
prohibit a certain class of publication definitions, what good does it do
to check that on the subscriber side?  Even more to the point, how can we
have a subscriber do that by relying on view columns that don't exist in
older versions?  I'm also quite concerned about anything that involves
subscribers examining row filter conditions; that sounds like a pretty
direct route to bugs involving unsolvability and the halting problem.

(But I've not read very much of this thread ... been a bit under the
weather the last couple weeks.  Maybe this actually is a sane solution.
It just doesn't sound like one at this level of detail.)

			regards, tom lane