Justin Pryzby <pry...@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 adding 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