psql/pg_dump vs. dollar signs in identifiers - Mailing list pgsql-hackers

From Tom Lane
Subject psql/pg_dump vs. dollar signs in identifiers
Date
Msg-id 23402.1184000272@sss.pgh.pa.us
Whole thread Raw
Responses Re: psql/pg_dump vs. dollar signs in identifiers
List pgsql-hackers
An example being discussed on the jdbc list led me to try this:

regression=# create table a$b$c (f1 int);
CREATE TABLE
regression=# \d a$b$c
Did not find any relation named "a$b$c".

It works if you use quotes:

regression=# \d "a$b$c"    Table "public.a$b$c"Column |  Type   | Modifiers
--------+---------+-----------f1     | integer |

The reason it doesn't work without quotes is that processSQLNamePattern()
thinks this:
            * Inside double quotes, or at all times if force_escape is true,            * quote regexp special
characterswith a backslash to avoid            * regexp errors.  Outside quotes, however, let them pass through
  * as-is; this lets knowledgeable users build regexp expressions            * that are more powerful than shell-style
patterns.

and of course $ is a regexp special character, so it bollixes up the
match.

Now, because we surround the pattern with ^...$ anyway, I can't offhand
see a use-case for putting $ with its regexp meaning into the pattern.
And since we do allow $ as a non-first character of identifiers, there
is a use-case for expecting it to be treated like an ordinary character.

So I'm thinking that $ ought to be quoted whether it's inside double
quotes or not.  This change would affect psql's describe commands as
well as pg_dump -t and -n patterns.

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Warm standby stall -- what debug info would help?
Next
From: "Simon Riggs"
Date:
Subject: Re: Warm standby stall -- what debug info would help?