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

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.

Thanks,

Stephen