Re: pg14 psql broke \d datname.nspname.relname - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg14 psql broke \d datname.nspname.relname
Date
Msg-id 2554506.1650382005@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg14 psql broke \d datname.nspname.relname  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Tue, Apr 19, 2022 at 10:00:01AM -0400, Robert Haas wrote:
>> (A) This is a new feature. Wait for v16.
>> (B) This is a bug fix. Commit it now and back-patch to v14.
>> (C) This is a cleanup that is OK to put into v15 even after feature
>> freeze but since it is a behavior change we shouldn't back-patch it.
>> I vote for (C). What do other people think?

> I thought the plan was to backpatch to v14.

> v14 psql had an unintentional behavior change, rejecting \d
> datname.nspname.relname.

I agree that the v14 behavior is a bug, so ordinarily I'd vote
for back-patching.

A possible objection to doing that is that the patch changes the
APIs of processSQLNamePattern and patternToSQLRegex.  We would avoid
making such a change in core-backend APIs in a minor release, but
I'm not certain whether there are equivalent stability concerns
for src/fe_utils/.

On the whole I'd vote for (B), with (C) as second choice.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: error handling in pqRowProcessor broken
Next
From: Andrew Dunstan
Date:
Subject: Re: Postgres perl module namespace