Thread: pgsql: Allow db.schema.table patterns, but complain about random garbag
Allow db.schema.table patterns, but complain about random garbage. psql, pg_dump, and pg_amcheck share code to process object name patterns like 'foo*.bar*' to match all tables with names starting in 'bar' that are in schemas starting with 'foo'. Before v14, any number of extra name parts were silently ignored, so a command line '\d foo.bar.baz.bletch.quux' was interpreted as '\d bletch.quux'. In v14, as a result of commit 2c8726c4b0a496608919d1f78a5abc8c9b6e0868, we instead treated this as a request for table quux in a schema named 'foo.bar.baz.bletch'. That caused problems for people like Justin Pryzby who were accustomed to copying strings of the form db.schema.table from messages generated by PostgreSQL itself and using them as arguments to \d. Accordingly, revise things so that if an object name pattern contains more parts than we're expecting, we throw an error, unless there's exactly one extra part and it matches the current database name. That way, thisdb.myschema.mytable is accepted as meaning just myschema.mytable, but otherdb.myschema.mytable is an error, and so is some.random.garbage.myschema.mytable. Mark Dilger, per report from Justin Pryzby and discussion among various people. Discussion: https://www.postgresql.org/message-id/20211013165426.GD27491%40telsasoft.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d2d35479796c3510e249d6fc72adbd5df918efbf Modified Files -------------- doc/src/sgml/ref/psql-ref.sgml | 17 +- src/bin/pg_amcheck/pg_amcheck.c | 27 +- src/bin/pg_amcheck/t/002_nonesuch.pl | 99 ++++- src/bin/pg_dump/pg_dump.c | 65 ++- src/bin/pg_dump/pg_dumpall.c | 13 +- src/bin/pg_dump/t/002_pg_dump.pl | 107 +++++ src/bin/psql/describe.c | 504 ++++++++++++++-------- src/fe_utils/string_utils.c | 129 ++++-- src/include/fe_utils/string_utils.h | 6 +- src/test/regress/expected/psql.out | 804 +++++++++++++++++++++++++++++++++++ src/test/regress/sql/psql.sql | 242 +++++++++++ 11 files changed, 1796 insertions(+), 217 deletions(-)
Re: pgsql: Allow db.schema.table patterns, but complain about random garbag
From
Andrew Dunstan
Date:
On 2022-04-20 We 11:52, Robert Haas wrote: > Allow db.schema.table patterns, but complain about random garbage. > > psql, pg_dump, and pg_amcheck share code to process object name > patterns like 'foo*.bar*' to match all tables with names starting in > 'bar' that are in schemas starting with 'foo'. Before v14, any number > of extra name parts were silently ignored, so a command line '\d > foo.bar.baz.bletch.quux' was interpreted as '\d bletch.quux'. In v14, > as a result of commit 2c8726c4b0a496608919d1f78a5abc8c9b6e0868, we > instead treated this as a request for table quux in a schema named > 'foo.bar.baz.bletch'. That caused problems for people like Justin > Pryzby who were accustomed to copying strings of the form > db.schema.table from messages generated by PostgreSQL itself and using > them as arguments to \d. > > Accordingly, revise things so that if an object name pattern contains > more parts than we're expecting, we throw an error, unless there's > exactly one extra part and it matches the current database name. > That way, thisdb.myschema.mytable is accepted as meaning just > myschema.mytable, but otherdb.myschema.mytable is an error, and so > is some.random.garbage.myschema.mytable. This has upset the buildfarm's msys2 animals. There appears to be some wildcard expansion going on that causes the problem. I don't know why it should here when it's not causing trouble elsewhere. I have tried changing the way the tests are quoted, without success. Likewise, setting SHELLOPTS=noglob didn't work. At this stage I'm fresh out of ideas to fix it. It's also quite possible that my diagnosis is wrong. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
> This has upset the buildfarm's msys2 animals. There appears to be some
> wildcard expansion going on that causes the problem. I don't know why it
> should here when it's not causing trouble elsewhere. I have tried
> changing the way the tests are quoted, without success. Likewise,
> setting SHELLOPTS=noglob didn't work.
> At this stage I'm fresh out of ideas to fix it. It's also quite possible
> that my diagnosis is wrong.
When I was looking at this patch, I thought the number of test cases
was very substantially out of line anyway. I suggest that rather
than investing a bunch of brain cells trying to work around this,
we just remove the failing test cases.
regards, tom lane
Re: pgsql: Allow db.schema.table patterns, but complain about random garbag
From
Andrew Dunstan
Date:
On 2022-04-22 Fr 10:04, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> This has upset the buildfarm's msys2 animals. There appears to be some >> wildcard expansion going on that causes the problem. I don't know why it >> should here when it's not causing trouble elsewhere. I have tried >> changing the way the tests are quoted, without success. Likewise, >> setting SHELLOPTS=noglob didn't work. >> At this stage I'm fresh out of ideas to fix it. It's also quite possible >> that my diagnosis is wrong. > When I was looking at this patch, I thought the number of test cases > was very substantially out of line anyway. I suggest that rather > than investing a bunch of brain cells trying to work around this, > we just remove the failing test cases. WFM. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com