database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-22 23:02:54 +03:00
Code

Adjust processSQLNamePattern() so that $ within the pattern is always matched

Browse Source 
literally, whether quoted or not.  Since we allow $ as a character within
identifiers, this behavior is useful, whereas the previous behavior of
treating it as the regexp ending anchor was nearly useless given that the
pattern is automatically anchored anyway.  This affects the arguments of
psql's \d commands as well as pg_dump's -n and -t switches.  Per discussion.
This commit is contained in:
Tom Lane 2007-07-10 00:21:31 +00:00
parent 6244c2dfff
commit ff481ca0d4
2 changed files with 24 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
doc/src/sgml/ref/psql-ref.sgml
View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.192 2007/06/28 06:40:16 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.193 2007/07/10 00:21:31 tgl Exp $
PostgreSQL documentation
-->
@ -1916,8 +1916,8 @@ lo_import 152801
<para>
A pattern that contains a dot (<literal>.</>) is interpreted as a schema
name pattern followed by an object name pattern. For example,
<literal>\dt foo*.bar*</> displays all tables whose table name
starts with <literal>bar</> that are in schemas whose schema name
<literal>\dt foo*.*bar*</> displays all tables whose table name
includes <literal>bar</> that are in schemas whose schema name
starts with <literal>foo</>. When no dot appears, then the pattern
matches only objects that are visible in the current schema search path.
Again, a dot within double quotes loses its special meaning and is matched
@ -1930,17 +1930,20 @@ lo_import 152801
expression special characters work as specified in
<xref linkend="functions-posix-regexp">, except for <literal>.</> which
is taken as a separator as mentioned above, <literal>*</> which is
translated to the regular-expression notation <literal>.*</>, and
<literal>?</> which is translated to <literal>.</>. You can emulate
translated to the regular-expression notation <literal>.*</>,
<literal>?</> which is translated to <literal>.</>, and
<literal>$</> which is matched literally. You can emulate
these pattern characters at need by writing
<literal>?</> for <literal>.</>,
<literal>(<replaceable class="parameter">R</replaceable>+|)</literal> for
<literal><replaceable class="parameter">R</replaceable>*</literal>, or
<literal>(<replaceable class="parameter">R</replaceable>|)</literal> for
<literal><replaceable class="parameter">R</replaceable>?</literal>.
Remember that the pattern must match the whole name, unlike the usual
interpretation of regular expressions; write <literal>*</> at the beginning
and/or end if you don't wish the pattern to be anchored.
<literal>$</> is not needed as a regular-expression character since
the pattern must match the whole name, unlike the usual
interpretation of regular expressions (in other words, <literal>$</>
is automatically appended to your pattern). Write <literal>*</> at the
beginning and/or end if you don't wish the pattern to be anchored.
Note that within double quotes, all regular expression special characters
lose their special meanings and are matched literally. Also, the regular
expression special characters are matched literally in operator name

14
src/bin/pg_dump/dumputils.c
View File

@ -8,7 +8,7 @@
* Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* $PostgreSQL: pgsql/src/bin/pg_dump/dumputils.c,v 1.36 2007/06/18 21:40:58 tgl Exp $
* $PostgreSQL: pgsql/src/bin/pg_dump/dumputils.c,v 1.37 2007/07/10 00:21:31 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -872,6 +872,18 @@ processSQLNamePattern(PGconn *conn, PQExpBuffer buf, const char *pattern,
appendPQExpBufferStr(&namebuf, "^(");
cp++;
}
else if (ch == '$')
{
/*
* Dollar is always quoted, whether inside quotes or not.
* The reason is that it's allowed in SQL identifiers, so
* there's a significant use-case for treating it literally,
* while because we anchor the pattern automatically there is
* no use-case for having it possess its regexp meaning.
*/
appendPQExpBufferStr(&namebuf, "\\$");
cp++;
}
else
{
/*