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

From Mark Dilger
Subject Re: pg14 psql broke \d datname.nspname.relname
Date
Msg-id 2F3734AB-5E1C-40F8-9E4B-DDDB108FAF25@enterprisedb.com
Whole thread Raw
In response to Re: pg14 psql broke \d datname.nspname.relname  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg14 psql broke \d datname.nspname.relname  (Robert Haas <robertmhaas@gmail.com>)
Re: pg14 psql broke \d datname.nspname.relname  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers

> On Oct 12, 2021, at 10:03 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Oct 12, 2021 at 12:57 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
>> I think there's an easy answer here that would satisfy everyone; two patches:
>> 0001 to fix the unintentional behavior change;
>> 0002 to reject garbage input: anything with more than 3 dot-separated
>>     components, or with 3 components where the first doesn't match
>>     current_database.
>>
>> 0001 would be backpatched to v14.
>>
>> If it turns out there's no consensus on 0002, or if it were really hard for
>> some reason, or (more likely) nobody went to the bother to implement it this
>> year, then that's okay.
>
> This might work, but I fear that 0001 would end up being substantially
> more complicated than a combined patch that solves both problems
> together.

Here is a WIP patch that restores the old behavior, just so you can eyeball how large it is.  (It passes check-world
andI've read it over once, but I'm not ready to stand by this as correct quite yet.)  I need to add a regression test
tomake sure this behavior is not accidentally changed in the future, and will repost after doing so. 


—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company




Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [RFC] building postgres with meson
Next
From: Mark Dilger
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname