Re: pg14 psql broke \d datname.nspname.relname
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
Robert Haas <robertmhaas@gmail.com>,
pgsql-hackers@postgresql.org
Date: 2021-10-12T02:09:03Z
Lists: 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 what they meant, and for backward compatibility reasons we define using the suffix d.e and ignoring the prefix a.b.c as the correct 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.relation format without ignoring the database portion, our client behavior is getting inconsistent. I'd like to leave the door open for someday supporting server.database.schema.relation format, too. I was just wondering when it 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
Commits
-
Remove some recently-added pg_dump test cases.
- 75a006beef6c 14.3 landed
- a66e722cc118 15.0 landed
-
Allow db.schema.table patterns, but complain about random garbage.
- 4a66300acd8c 14.3 landed
- d2d35479796c 15.0 landed
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Factor pattern-construction logic out of processSQLNamePattern.
- 2c8726c4b0a4 14.0 cited