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

On Mon, Oct 11, 2021 at 10:33 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Mon, Oct 11, 2021 at 7:09 PM Mark Dilger
> <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> > I was just wondering when it might be time to stop being lenient in psql and instead reject malformed identifiers.
>
> I suppose that I probably wouldn't have chosen this behavior in a
> green field situation. But Hyrum's law tells us that there are bound
> to be some number of users relying on it. I don't think that it's
> worth inconveniencing those people without getting a clear benefit in
> return.
>
> Being lenient here just doesn't have much downside in practice, as
> evidenced by the total lack of complaints about that lenience.

I find it kind of surprising to find everyone agreeing with this
argument. I mean, PostgreSQL users are often quick to criticize MySQL
for accepting 0000-00-00 as a date, because it isn't, and you
shouldn't accept garbage and do stuff with it as if it were valid
data. But by the same argument, accepting a database name that we know
is not correct as a request to show data in the current database seems
wrong to me.

I completely agree that somebody might be relying on the fact that \d
thisdb.someschema.sometable does something sensible when logged into
thisdb, but surely no user is relying on \d
jgldslghksdghjsgkhsdgjhskg.someschema.sometable is going to just
ignore the leading gibberish. Nor do I understand why we'd want to
ignore the leading gibberish. Saying, as Tom did, that nobody has
complained about that behavior is just another way of saying that
nobody tested it. Surely if someone had, it wouldn't be like this.

--
Robert Haas
EDB: http://www.enterprisedb.com