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

On 10/12/21 5:19 PM, Stephen Frost wrote:
> Greetings,
> 
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Tue, Oct 12, 2021 at 10:31 AM Tom Lane <tgl@sss.pgh.pa.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 dlsgjdsghj.sdhg.l.dsg.jkhsdg.foo.bar to work
>> like \d foo.bar, 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