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 921F85F5-D7B4-4525-9CA8-FE4CBFCAC149@enterprisedb.com
Whole thread Raw
In response to Re: pg14 psql broke \d datname.nspname.relname  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> On Oct 12, 2021, at 7:30 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.

I completely agree that we need to fix this.  My question was only whether "fix" means to make it accept
database.schema.tableor whether it means to accept any.prefix.at.all.schema.table.  It sounds like more people like the
latter,so I'll go with that unless this debate rages on and a different conclusion is reached. 

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






pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: storing an explicit nonce
Next
From: Stephen Frost
Date:
Subject: Re: storing an explicit nonce