> On Oct 12, 2021, at 10:18 AM, Mark Dilger <mark.dil...@enterprisedb.com> 
> wrote:
> 
> Here is a WIP patch that restores the old behavior, just so you can eyeball 
> how large it is.  (It passes check-world and I've read it over once, but I'm 
> not ready to stand by this as correct quite yet.)  I need to add a regression 
> test to make sure this behavior is not accidentally changed in the future, 
> and will repost after doing so.

I wasn't thinking critically enough about how psql handles \d when I accepted 
Justin's initial characterization of the bug.  The psql client has never 
thought about the stuff to the left of the schema name as a database name, even 
if some users thought about it that way.  It also doesn't think about the 
pattern as a literal string.

The psql client's interpretation of the pattern is a bit of a chimera, 
following shell glob patterns for some things and POSIX regex rules for others. 
 The reason for that is shell glob stuff gets transliterated into the 
corresponding POSIX syntax, but non-shell-glob stuff is left in tact, with the 
one outlier being dots, which have a very special interpretation.  The 
interpretation of a dot as meaning "match one character" is not a shell glob 
rule but a regex one, and one that psql never supported because it split the 
pattern on all dots and threw away stuff to the left.  There was therefore 
never an opportunity for an unquoted dot to make it through to the POSIX 
regular expression for processing.  For other regex type stuff, it happily 
passed it through to the POSIX regex, so that the following examples work even 
though they contain non-shell-glob regex stuff:

v13=# create table ababab (i integer);
CREATE TABLE

v13=# \dt (ab){3}
           List of relations
 Schema |  Name  | Type  |    Owner    
--------+--------+-------+-------------
 public | ababab | table | mark.dilger
(1 row)

v13=# \dt pg_catalog.pg_clas{1,2}
              List of relations
   Schema   |   Name   | Type  |    Owner    
------------+----------+-------+-------------
 pg_catalog | pg_class | table | mark.dilger

v13=# \dt pg_catalog.pg_[am]{1,3}
            List of relations
   Schema   | Name  | Type  |    Owner    
------------+-------+-------+-------------
 pg_catalog | pg_am | table | mark.dilger
(1 row)

Splitting the pattern on all the dots and throwing away any additional leftmost 
fields is a bug, and when you stop doing that, passing additional dots through 
to the POSIX regular expression for processing is the most natural thing to do. 
 This is, in fact, how v14 works.  It is a bit debatable whether treating the 
first dot as a separator and the additional dots as stuff to be passed through 
is the right thing, so we could call the v14 behavior a mis-feature, but it's 
not as clearcut as the discussion upthread suggested.  Reverting to v13 
behavior seems wrong, but I'm now uncertain how to proceed.

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





Reply via email to