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 A76B6CAA-B740-4979-BB61-97E5B31334E4@enterprisedb.com
Whole thread Raw
In response to Re: pg14 psql broke \d datname.nspname.relname  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg14 psql broke \d datname.nspname.relname  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers

> On Oct 11, 2021, at 4:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> You are attacking a straw man here.  To use a period in an identifier,
> you have to double-quote it; that's the same in SQL or \d.

That's a strange argument.  If somebody gives an invalid identifier, we shouldn't assume they know the proper use of
quotations. Somebody asking for a.b.c.d.e is clearly in the dark about something.  Maybe it's the need to quote the
"a.b"part separately from the "c.d.e" part, or maybe it's something else.  There are lots of reasonable guesses about
whatthey meant, and for backward compatibility reasons we define using the suffix d.e and ignoring the prefix a.b.c as
thecorrect answer.  That's a pretty arbitrary thing to do, but it has the advantage of being backwards compatible. 

>> I expect I'll have to submit a patch restoring the old behavior, but I wonder if that's the best direction to go.
>
> I do not understand why you're even questioning that.  The old
> behavior had stood for a decade or two without complaints.

I find the backward compatibility argument appealing, but since we have clients that understand the full
database.schema.relationformat without ignoring the database portion, our client behavior is getting inconsistent.  I'd
liketo leave the door open for someday supporting server.database.schema.relation format, too.  I was just wondering
whenit might be time to stop being lenient in psql and instead reject malformed identifiers. 

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






pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: is possible an remote access to some macos?
Next
From: Michael Paquier
Date:
Subject: Re: More business with $Test::Builder::Level in the TAP tests