Re: Remove source code display from \df+?
Isaac Morland <isaac.morland@gmail.com>
From: Isaac Morland <isaac.morland@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
Justin Pryzby <pryzby@telsasoft.com>, Pavel Stehule <pavel.stehule@gmail.com>,
Magnus Hagander <magnus@hagander.net>, pgsql-hackers@postgresql.org
Date: 2023-01-22T21:28:21Z
Lists: pgsql-hackers
On Sun, 22 Jan 2023 at 15:04, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Isaac Morland <isaac.morland@gmail.com> writes: > > On Sun, 22 Jan 2023 at 14:26, Alvaro Herrera <alvherre@alvh.no-ip.org> > > wrote: > >> This one would fail the sanity check that all roles created by > >> regression tests need to have names that start with "regress_". > > > Thanks for the correction. Now I feel like I've skipped some of the > > readings! > > Updated patch attached. Informally, I am adopting the regress_* policy > for > > all object types. > > That's excessive. The policy Alvaro mentions applies to globally-visible > object names (i.e., database, role, and tablespace names), and it's there > to try to ensure that doing "make installcheck" against a live > installation won't clobber any non-test-created objects. There's no point > in having such a policy within a test database --- its most likely effect > there would be to increase the risk that different test scripts step on > each others' toes. If you feel a need for a name prefix for non-global > objects, use something based on the name of your test script. > I already used a test-specific prefix, then added "regress_" in front. Point taken, however, on the difference between global and non-global objects. But now I'm having a problem I don't understand: the CI are still failling, but not in the psql test. Instead, I get this: [20:11:17.624] +++ tap check in src/bin/pg_upgrade +++ [20:11:17.624] [20:09:11] t/001_basic.pl ....... ok 106 ms ( 0.00 usr 0.00 sys + 0.06 cusr 0.02 csys = 0.08 CPU) [20:11:17.624] [20:11:17.624] # Failed test 'old and new dumps match after pg_upgrade' [20:11:17.624] # at t/002_pg_upgrade.pl line 362. [20:11:17.624] # got: '1' [20:11:17.624] # expected: '0' [20:11:17.624] # Looks like you failed 1 test of 13. [20:11:17.624] [20:11:17] t/002_pg_upgrade.pl .. [20:11:17.624] Dubious, test returned 1 (wstat 256, 0x100) [20:11:17.624] Failed 1/13 subtests [20:11:17.624] [20:11:17] [20:11:17.624] [20:11:17.624] Test Summary Report [20:11:17.624] ------------------- [20:11:17.624] t/002_pg_upgrade.pl (Wstat: 256 Tests: 13 Failed: 1) [20:11:17.624] Failed test: 13 [20:11:17.624] Non-zero exit status: 1 [20:11:17.624] Files=2, Tests=21, 126 wallclock secs ( 0.01 usr 0.00 sys + 6.65 cusr 3.95 csys = 10.61 CPU) [20:11:17.624] Result: FAIL [20:11:17.624] make[2]: *** [Makefile:55: check] Error 1 [20:11:17.625] make[1]: *** [Makefile:43: check-pg_upgrade-recurse] Error 2 As far as I can tell this is the only failure and doesn’t have anything to do with my change. Unless the objects I added are messing it up? Unlike when the psql regression test was failing, I don’t see an indication of where I can see the diffs.
Commits
-
Show "internal name" not "source code" in psql's \df+ command.
- 3dfae91f7a12 16.0 landed