pgsql: doc: Add links to tables
doc: Add links to tables Formal tables should generally have an xref in the text that points to them. Add them here. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/826be1ffb28dde083552150243dbbdcac55ab28e Modified Files -- doc/src/sgml/config.sgml | 7 --- doc/src/sgml/logical-replication.sgml | 7 ++- 2 files changed, 10 insertions(+), 4 deletions(-)
Re: pgsql: Allow db.schema.table patterns, but complain about random garbag
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
Re: pgsql: Allow db.schema.table patterns, but complain about random garbag
Andrew Dunstan 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
On 2022-04-22 Fr 10:04, Tom Lane wrote: > Andrew Dunstan 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
pgsql: Remove some recently-added pg_dump test cases.
Remove some recently-added pg_dump test cases. Commit d2d35479796c3510e249d6fc72adbd5df918efbf included a pretty extensive set of test cases, and some of them don't work on all of our Windows machines. This happens because IPC::Run expands its arguments as shell globs on a few machines, but doesn't on most of the buildfarm. It might be good to fix that problem systematically somehow, but in the meantime, there are enough test cases for this commit that it seems OK to just remove the ones that are failing. Discussion: http://postgr.es/m/[email protected] Discussion: http://postgr.es/m/CA+TgmoYRGUcFBy6VgN0+Pn4f6Wv=2h0hzluphqsy6vc8ba7...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a66e722cc1180cd7a2046fb552195a7d7703a592 Modified Files -- src/bin/pg_dump/t/002_pg_dump.pl | 30 -- 1 file changed, 30 deletions(-)
Re: pgsql: Remove some recently-added pg_dump test cases.
Robert Haas writes: > Remove some recently-added pg_dump test cases. Um ... you needed to do that in v14, too. regards, tom lane
pgsql: Test ALIGNOF_DOUBLE==4 compatibility under ALIGNOF_DOUBLE==8.
Test ALIGNOF_DOUBLE==4 compatibility under ALIGNOF_DOUBLE==8. Today's test case detected alignment problems only when executing on AIX. This change lets popular platforms detect the same problems. Reviewed by Masahiko Sawada. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c1da0acbb06e9175044b436d14c51cef03339109 Modified Files -- src/test/regress/expected/sanity_check.out | 10 +- src/test/regress/expected/test_setup.out | 2 +- src/test/regress/regress.c | 16 ++-- src/test/regress/sql/sanity_check.sql | 6 +++--- src/test/regress/sql/test_setup.sql| 2 +- 5 files changed, 16 insertions(+), 20 deletions(-)
