\dn [PATTERN] handling not quite right...
От | Sean Chittenden |
---|---|
Тема | \dn [PATTERN] handling not quite right... |
Дата | |
Msg-id | 142C8AE9-76D0-11D8-89C3-000A95C705DC@chittenden.org обсуждение исходный текст |
Ответы |
Re: \dn [PATTERN] handling not quite right...
|
Список | 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)$' ORDER BY 1; ************************** 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? -sc -- Sean Chittenden
В списке pgsql-bugs по дате отправления: