Re: pgsql: Allow db.schema.table patterns, but complain about random garbag
От | Andrew Dunstan |
---|---|
Тема | Re: pgsql: Allow db.schema.table patterns, but complain about random garbag |
Дата | |
Msg-id | 3a190754-b2b0-d02b-dcfd-4ec1610ffbcb@dunslane.net обсуждение исходный текст |
Ответ на | pgsql: Allow db.schema.table patterns, but complain about random garbag (Robert Haas <rhaas@postgresql.org>) |
Ответы |
Re: pgsql: Allow db.schema.table patterns, but complain about random garbag
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: