From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Superuser can permit passwordless connections on
 postgres_fdw
In-reply-to: <20191220120208.GA4258@paquier.xyz>
References: <E1iiBFm-0001RN-N2@gemulon.postgresql.org>
 <20191220120208.GA4258@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Fri, 20 Dec 2019 21:02:08 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <11296.1576868677.1@sss.pgh.pa.us>
Date: Fri, 20 Dec 2019 14:04:37 -0500
Message-ID: <11297.1576868677@sss.pgh.pa.us>
Precedence: bulk

[ redirecting to -hackers ]

Michael Paquier <michael@paquier.xyz> writes:
> On Fri, Dec 20, 2019 at 05:55:10AM +0000, Andrew Dunstan wrote:
>> Superuser can permit passwordless connections on postgres_fdw

> After this commit a couple of buildfarm animals are unhappy with the
> regression tests of postgres_fdw:

Yeah, the buildfarm is *very* unhappy with this.

>  CREATE ROLE nosuper NOSUPERUSER;
> +WARNING:  roles created by regression test cases should have names
>  starting with "regress_"

That one is just failure to follow the guidelines, and is easily
fixed by adjusting the test case.

> These is also a second type of failure:
> -HINT:  Valid options in this context are: [...] krbsrvname [...]
> +HINT:  Valid options in this context are: [...]
> The diff here is that krbsrvname is not part of the list of valid
> options.  Anyway, as this list is build-dependent, I think that this
> test needs some more design effort.

This is a bit messier.  But I think that the discrepancy is not
really the fault of this patch: rather, it's a bug in the way the
GSS support was put into libpq.  I thought we had a policy that
all builds would recognize all possible parameters and then
perhaps fail later.  Certainly the SSL parameters are implemented
that way.  The #if's disabling GSS stuff in PQconninfoOptions[]
are just broken, according to that policy.

			regards, tom lane