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 1pJiSa-0003X3-6I for pgsql-hackers@arkaria.postgresql.org; Sun, 22 Jan 2023 22:05:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pJiSZ-0002MU-1E for pgsql-hackers@arkaria.postgresql.org; Sun, 22 Jan 2023 22:05:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pJiSY-0002Lm-Mk for pgsql-hackers@lists.postgresql.org; Sun, 22 Jan 2023 22:05:06 +0000 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pJiSW-0001Aj-GP for pgsql-hackers@postgresql.org; Sun, 22 Jan 2023 22:05:06 +0000 Received: by mail-pj1-x1034.google.com with SMTP id u1-20020a17090a450100b0022936a63a21so13685919pjg.4 for ; Sun, 22 Jan 2023 14:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XgOuyam4/Bw+JURNozZZNSbE3AZKKe5rlJguaiHWoZo=; b=F34SUzXtibsXX6/TKA42Fk+RfkwXj7nQIKoFuMbjHW6Nn9zf9wUDGP/JPXof44h0ui TZxkM+FINAzhZwuqvraFG0eNkEpTjQhHFH9cM+Sm9szyc0PcVCV8wj6dxYn16GYXquav q1d6Bkhx+r240sG/hEl4WGfd951WzoIHO2Z7153PJBMZtkpk9T96zirY5yyfmg/28/K9 v81HESohEggrNAajDrox/86hbMIcpK/Xzq1XkIOsUZ2KPcJJxXO3Ll7mD2k4MJiaWVoA q/Dxb+pmyaoTrr+TCVXH+3G3GH/SScJMjU7/K+7Pjb5o/rKYPGx5/QZIBKaPnGjVNkfU hcJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XgOuyam4/Bw+JURNozZZNSbE3AZKKe5rlJguaiHWoZo=; b=7s+CrxCmCESQ4677Jqx0amOj/Cg/r2dIJ5XQ8l1TX2rCcOKvKfv22i4ti9rwulxTV6 L5SgRQawgqwSJ7sZakNruwfn0ImKw3HnvVP+oGnQf1KF8hdYj47aAapn8AV2iZdNW1CX Gj/2APxwHXRUzkkg3Scoxc7flBuL+pL6LTgGMhADYNx2rBzmxsEKCS+GPYJ5fcZvzS8b jRTdqQrF9AN/phIw8M09FOP65AaV5YOdt1uztaMWJAAzNY9r2InWxGAeBlzfKtPQ4E0+ XX4SJQ9C3YC7qHn+gI/Nl1ItuxTn34llSD5etJhp4j1XH3PaSb/lrxOpo6KIQlFtC9mR zcFw== X-Gm-Message-State: AFqh2kr4v4vxXF/sv8Sbx+aZ+BDKCZXVUq+Lk3F/Zfc05f5Jl1aQcxIv +lHa4jrVoXKF8g7PNkFwmJdR1TWfjjtRLR3YBi4= X-Google-Smtp-Source: AMrXdXuzgaQUjjku3snUVAX7NEKFAj2f+M4RPp8lNglq9a2C5kuqZ6tuh75dLtYggvGXlqb/T+3bIaHsJRv4t4AgQpY= X-Received: by 2002:a17:902:b20c:b0:194:7cb3:2527 with SMTP id t12-20020a170902b20c00b001947cb32527mr2225597plr.4.1674425101732; Sun, 22 Jan 2023 14:05:01 -0800 (PST) MIME-Version: 1.0 References: <20230122191549.5b35ulimlvz42y7l@alvherre.pgsql> <1413123.1674417854@sss.pgh.pa.us> <20230122215628.GR13860@telsasoft.com> In-Reply-To: <20230122215628.GR13860@telsasoft.com> From: Isaac Morland Date: Sun, 22 Jan 2023 17:04:50 -0500 Message-ID: Subject: Re: Remove source code display from \df+? To: Justin Pryzby Cc: Tom Lane , Alvaro Herrera , Pavel Stehule , Magnus Hagander , pgsql-hackers@postgresql.org Content-Type: multipart/alternative; boundary="00000000000064529c05f2e17938" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000064529c05f2e17938 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 22 Jan 2023 at 16:56, Justin Pryzby wrote: > On Sun, Jan 22, 2023 at 03:04:14PM -0500, Tom Lane wrote: > > That's excessive. The policy Alvaro mentions applies to globally-visible > > object names (i.e., database, role, and tablespace names), and it's the= re > > 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 effe= ct > > 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. > > But we *are* talking about the role to be created to allow stable output > of \df+ , so it's necessary to name it "regress_*". To appease > ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, and to avoid clobbering > global objects during "installcheck". > Tom is talking about my informal policy of prefixing all objects. Only global objects need to be prefixed with regress_, but I prefixed everything I created (functions as well as the role). I actually called the role regress_psql_df and used that entire role name as the prefix of my function names, so I think it unlikely that I=E2=80=99ll collide with anyth= ing else. --00000000000064529c05f2e17938 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, 22 Jan 2023 at 16:56, Justin Pryz= by <pryzby@telsasoft.com>= wrote:
On Sun, Jan 22= , 2023 at 03:04:14PM -0500, Tom Lane wrote:

> That's excessive.=C2=A0 The policy Alvaro mentions applies to glob= ally-visible
> object names (i.e., database, role, and tablespace names), and it'= s there
> to try to ensure that doing "make installcheck" against a li= ve
> installation won't clobber any non-test-created objects.=C2=A0 The= re's no point
> in having such a policy within a test database --- its most likely eff= ect
> there would be to increase the risk that different test scripts step o= n
> each others' toes.=C2=A0 If you feel a need for a name prefix for = non-global
> objects, use something based on the name of your test script.

But we *are* talking about the role to be created to allow stable output of \df+ , so it's necessary to name it "regress_*".=C2=A0 To = appease
ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, and to avoid clobbering
global objects during "installcheck".

Tom is talking about my informal policy of prefixing all objects. = Only global objects need to be prefixed with regress_, but I prefixed every= thing I created (functions as well as the role). I actually called the role= =C2=A0regress_psql_df and used that entire role name as the prefix of my fu= nction names, so I think it unlikely that I=E2=80=99ll collide with anythin= g else.
=C2=A0
--00000000000064529c05f2e17938--