Skip site navigation (1) Skip section navigation (2)

\dn [PATTERN] handling not quite right...

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: PostgreSQL Bugs List <pgsql-bugs(at)postgresql(dot)org>
Subject: \dn [PATTERN] handling not quite right...
Date: 2004-03-15 22:28:27
Message-ID: (view raw or flat)
Lists: pgsql-bugs
I haven't looked in great detail into why this is happpening, but it 
seems as though processNamePattern() doesn't handle ?'s correctly in 
the negative lookahead context correctly.

1) \dn [pattern] strips ?'s and replaces them with periods.  This may 
be intentional (as the comment in describe.c suggests, converting input 
from shell-style wildcards gets converted into regexp notation), but is 
quite annoying.  Ex:

test=# \dn foo(?!_log|_shadow)
********* QUERY **********
SELECT n.nspname AS "Name",
        u.usename AS "Owner"
FROM pg_catalog.pg_namespace n LEFT JOIN pg_catalog.pg_user u
        ON n.nspowner=u.usesysid
WHERE   (n.nspname NOT LIKE 'pg\\_temp\\_%' OR
                  n.nspname = (pg_catalog.current_schemas(true))[1])
       AND n.nspname ~ '^foo(.!_log|_shadow)$'

Which is incorrect, IMHO.  Instead the last bit of the query should be:

	AND n.nspname ~ '^foo(?!_log|_shadow)$'

2) This brings up a large deficiency with the way that \d? [pattern] 
handling is done in psql(1).  It'd be slick if there was a way to have 
psql's pattern routine look at the first non-whitespace character or 
two to change change the structure of the query.  Something like \dn 
!.*_shadow% would change the RE operator from ~ to !~ and \dn %bar% 
would translate to LIKE('bar%').  Doing the regexp equiv of 
!LIKE('%_shadow') isn't trivial because '^.*(?!_shadow)$' doesn't 
return the expected result for various reasons.  Oh!  This'd be a "gun 
pointed at foot" feature, but having the first character being an = 
would, without escaping, drop the remainder of the input directly into 
the query (ex: \dn =nspname != (LIKE('%_log') OR LIKE('%_shadow'))).  
Maybe a psql(1) variable that changes the behavior of the pattern 
queries from using an RE to a LIKE statement could also be a 
possibility.  The more I think about this, a leading pipe could be used 
to pipe the output to a utility, so that \dn | egrep -v '(log|shadow)  
would work and would be the easiest solution.

Maybe a better "bug report" would be, what's the suggested way of doing:

	n.nspname !~ '_(log|shadow)$'?

from a list pattern?


Sean Chittenden


pgsql-bugs by date

Next:From: Tom LaneDate: 2004-03-15 23:10:33
Subject: Re: \dn [PATTERN] handling not quite right...
Previous:From: PostgreSQL Bugs ListDate: 2004-03-15 11:49:50
Subject: BUG #1101: install-error

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group