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

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg14 psql broke \d datname.nspname.relname
Date: 2021-10-11 21:47:59
Message-ID: 7839D267-AB86-4155-A7B7-8B5866AD83FA@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Oct 11, 2021, at 2:24 PM, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> This commit broke psql \d datname.nspname.relname
>
> commit 2c8726c4b0a496608919d1f78a5abc8c9b6e0868
> Author: Robert Haas <rhaas(at)postgresql(dot)org>
> Date: Wed Feb 3 13:19:41 2021 -0500
>
> Factor pattern-construction logic out of processSQLNamePattern.
> ...
> patternToSQLRegex is a little more general than what is required
> by processSQLNamePattern. That function is only interested in
> patterns that can have up to 2 parts, a schema and a relation;
> but patternToSQLRegex can limit the maximum number of parts to
> between 1 and 3, so that patterns can look like either
> "database.schema.relation", "schema.relation", or "relation"
> depending on how it's invoked and what the user specifies.
>
> processSQLNamePattern only passes two buffers, so works exactly
> the same as before, always interpreting the pattern as either
> a "schema.relation" pattern or a "relation" pattern. But,
> future callers can use this function in other ways.
>
> |$ LD_LIBRARY_PATH=tmp_install/usr/local/pgsql/lib/ src/bin/psql/psql -h /tmp regression
> |psql (15devel)
> |Type "help" for help.
> |regression=# \d regresion.public.bit_defaults
> |Did not find any relation named "regresion.public.bit_defaults".
> |regression=# \d public.bit_defaults
> | Table "public.bit_defaults"
> |...
>
> This worked before v14 (even though the commit message says otherwise).
>
> |$ /usr/lib/postgresql/13/bin/psql -h /tmp regression
> |psql (13.2 (Debian 13.2-1.pgdg100+1), server 15devel)
> |...
> |regression=# \d regresion.public.bit_defaults
> | Table "public.bit_defaults"
> |...

I can only assume that you are intentionally misspelling "regression" as "regresion" (with only one "s") as part of the test. I have not checked if that worked before v14, but if it ignored the misspelled database name before v14, and it rejects it now, I'm not sure that counts as a bug.

Am I misunderstanding your bug report?


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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-10-11 22:04:01 Re: pg14 psql broke \d datname.nspname.relname
Previous Message Mark Dilger 2021-10-11 21:41:31 Re: BUG #17212: pg_amcheck fails on checking temporary relations