Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pJioi-0004ZB-Bf for pgsql-hackers@arkaria.postgresql.org; Sun, 22 Jan 2023 22:28:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pJiof-0007Zq-Ef for pgsql-hackers@arkaria.postgresql.org; Sun, 22 Jan 2023 22:27:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pJiof-0007Zg-3p for pgsql-hackers@lists.postgresql.org; Sun, 22 Jan 2023 22:27:57 +0000 Received: from mail-il1-x136.google.com ([2607:f8b0:4864:20::136]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pJiob-0002kP-Bp for pgsql-hackers@postgresql.org; Sun, 22 Jan 2023 22:27:55 +0000 Received: by mail-il1-x136.google.com with SMTP id i17so5260736ila.9 for ; Sun, 22 Jan 2023 14:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=iwIcXtXNszwqNcnQOWAUJwv3wfs940R8vbnz16PuFHU=; b=bL/qVYkwTkJ3fXCbSWg6F+9PZzDSC1s41ztQbvt2CK04RJeFDuA4JlBV5KH1A7gFRw 8lyZKZS1zloZdQ2UPcM0wwZm3bBIueQTfoRe1BcCq3j7hPqrEutvEwsY+29tYAj5O3gD mg32/c1GO4OX6igvTnIzdU/FgOFq8JA2555TE+9cxB4nfz/sKB5raDxGRsqy5jro4b3p j+PDfX0Ewaft5oT6XkURCpyT0uVjtx3kxtMjPalA941ztZyWHlJTMd3KJ1fBT4SrUL17 grIJhovnVtGmvY2g2N8CshbBuj4vfec4jlhxTfrD1rPvgL0/occ3Uv8hg2Eu3/9BcEpx ofZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iwIcXtXNszwqNcnQOWAUJwv3wfs940R8vbnz16PuFHU=; b=2/Ls4a/HXHDzID6qnu81GkCW9uuSonMtUhmUlXzr79DVHYEDurMSxR4xQL0AY7//YB tiSsYhRCyqFSWsMRc75GUvH57H//A+qzrA8mekOiQrhL4Impz3soYtjAyUunieQGNTkh zJ7R49BXA697HSr9dMnDHTEXlEoLe8s12kxZjW5Xbc0S08weWI/2s5hbuFkhp5Xxt5b5 sFcmf/hkCZpqExN8wPAo+u+133vcKneuXCecirAxR56wacXovukhHWb90KZVoNqb8dvZ 5iDEAuubOItkyGqIeecoJRXU7eN/PX/CFrmnZ+ivDmK+QJrjJAjGVI4R+Dn2aDGnVVIZ jIRg== X-Gm-Message-State: AFqh2ko4mFekiJO267Yy2aoEayomgSThVLqYbywyqv/L/L70c+9VTzpV zpJ5MMprLVi9Pb1eTy8Mo5725g== X-Google-Smtp-Source: AMrXdXugONjok7q3mVTmx2aTDnftklZNPC/a5Uoc07jIJNTE0l139X6E1B1o0az4ssSnR3CiIvpUUw== X-Received: by 2002:a05:6e02:1a6c:b0:30f:40fc:7a2b with SMTP id w12-20020a056e021a6c00b0030f40fc7a2bmr12953769ilv.32.1674426472655; Sun, 22 Jan 2023 14:27:52 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id y16-20020a920910000000b0030bfd384821sm9752627ilg.81.2023.01.22.14.27.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Jan 2023 14:27:52 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 1F75B800A27; Sun, 22 Jan 2023 16:27:51 -0600 (CST) Date: Sun, 22 Jan 2023 16:27:51 -0600 From: Justin Pryzby To: Isaac Morland Cc: Tom Lane , Alvaro Herrera , Pavel Stehule , Magnus Hagander , pgsql-hackers@postgresql.org Subject: Re: Remove source code display from \df+? Message-ID: <20230122222750.GS13860@telsasoft.com> References: <20230122191549.5b35ulimlvz42y7l@alvherre.pgsql> <1413123.1674417854@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Jan 22, 2023 at 04:28:21PM -0500, Isaac Morland wrote: > On Sun, 22 Jan 2023 at 15:04, Tom Lane wrote: > > > Isaac Morland writes: > > > On Sun, 22 Jan 2023 at 14:26, Alvaro Herrera > > > 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