On Sun, Jan 22, 2023 at 04:28:21PM -0500, Isaac Morland wrote: > On Sun, 22 Jan 2023 at 15:04, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > Isaac Morland <isaac.morl...@gmail.com> writes: > > > On Sun, 22 Jan 2023 at 14:26, Alvaro Herrera <alvhe...@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 +++
You'll find the diff in the "artifacts", but not a separate "diff" file. https://api.cirrus-ci.com/v1/artifact/task/6146418377752576/testrun/build/testrun/pg_upgrade/002_pg_upgrade/log/regress_log_002_pg_upgrade CREATE FUNCTION public.regress_psql_df_sql() RETURNS void LANGUAGE sql BEGIN ATOMIC - SELECT NULL::text; + SELECT NULL::text AS text; END; It's failing because after restoring the function, the column is named "text" - maybe it's a bug. Tom's earlier point was that neither the function nor its owner needs to be preserved (as is done to exercise pg_dump/restore/upgrade - surely functions are already tested). Dropping it when you're done running \df will avoid any possible issue with pg_upgrade. Were you able to test with your own github account ? -- Justin