From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Remove source code display from \df+? |
Date: | 2023-01-22 21:56:28 |
Message-ID: | 20230122215628.GR13860@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jan 22, 2023 at 03:04:14PM -0500, Tom Lane wrote:
> Isaac Morland <isaac(dot)morland(at)gmail(dot)com> writes:
> > On Sun, 22 Jan 2023 at 14:26, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.
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".
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-01-22 22:02:35 | Re: run pgindent on a regular basis / scripted manner |
Previous Message | Justin Pryzby | 2023-01-22 21:33:11 | Re: pg_stats and range statistics |