Re: pg14 psql broke \d datname.nspname.relname

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg14 psql broke \d datname.nspname.relname
Date: 2021-10-12 16:52:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 10/12/21 5:19 PM, Stephen Frost wrote:
> Greetings,
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Tue, Oct 12, 2021 at 10:31 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> If the behavior v14 had implemented were "throw an error if the
>>> first word doesn't match the current database name", perhaps nobody
>>> would have questioned it. But that's not what we have. It's fairly
>>> clear that neither you nor Mark thought very much about this case,
>>> let alone tested it. Given that, I am not very pleased that you
>>> are retroactively trying to justify breaking it by claiming that
>>> it was already broken. It's been that way since 7.3 implemented
>>> schemas, more or less, and nobody's complained about it. Therefore
>>> I see little argument for changing that behavior. Changing it in
>>> an already-released branch is especially suspect.
>> Oh, give me a break. The previous behavior obviously hasn't been
>> tested either, and is broken on its face. If someone *had* complained
>> about it, I imagine you would have promptly fixed it and likely
>> back-patched the fix, probably in under 24 hours from the time of the
>> report. I find it difficult to take seriously the contention that
>> anyone is expecting \d to work
>> like \d, or that they would even prefer that behavior over an
>> error message. You're carefully avoiding addressing that question in
>> favor of having a discussion of backward compatibility, but a better
>> term for what we're talking about here would be bug-compatibility.
> I tend to agree with Robert on this particular case. Accepting random
> nonsense there isn't a feature or something which really needs to be
> preserved. For my 2c, I would hope that one day we will be able to
> accept other database names there and if that happens, what then? We'd
> "break" these cases anyway. Better to be clear that such nonsense isn't
> intended to be accepted and clean that up. I do think it'd be good to
> accept the current database name there as that's reasonable.

I am going to throw my hat in with Robert and Stephen, too. At least
for 15 if we don't want to change this behavior in back branches.
Vik Fearing

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-10-12 16:57:45 Re: pg14 psql broke \d datname.nspname.relname
Previous Message Peter Geoghegan 2021-10-12 16:44:25 Re: pg14 psql broke \d datname.nspname.relname