Re: Remove source code display from \df+? - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: Remove source code display from \df+?
Date
Msg-id CAMsGm5crtf+JOWh+n3v=9YAwonT2P_bgcdfn2SVxCK7pjxqG-g@mail.gmail.com
Whole thread Raw
In response to Re: Remove source code display from \df+?  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Sun, 22 Jan 2023 at 16:56, Justin Pryzby <pryzby@telsasoft.com> 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 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.

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’ll collide with anything else.
 

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: run pgindent on a regular basis / scripted manner
Next
From: Justin Pryzby
Date:
Subject: Re: Remove source code display from \df+?