Re: Naming of gss_accept_deleg

2023-05-22 Thread Tom Lane 
Abhijit Menon-Sen  writes:
> Here's the diff,

Pushed, thanks.

> but the 0/1 values of settings like sslsni and
> sslcompression don't seem to be validated anywhere, unlike the string
> options in connectOptions2, so I didn't do anything for gssdelegation.

Yeah.  Perhaps it's worth adding code to validate boolean options,
but since nobody has noticed the lack of that for decades, I'm not
in a hurry to (especially not in a last-minute patch).

Also, I noticed that PGGSSDELEGATION had not been added to the lists of
environment variables to unset in pg_regress.c and Test/Utils.pm.
Dealt with that in the same commit.

regards, tom lane

Re: Naming of gss_accept_deleg

2023-05-22 Thread Tom Lane 
Abhijit Menon-Sen  writes:
> Here's the diff, but the 0/1 values of settings like sslsni and
> sslcompression don't seem to be validated anywhere, unlike the string
> options in connectOptions2, so I didn't do anything for gssdelegation.

Thanks!  I'll set to work on this.  I assume we want to squeeze
it into beta1, so there's not much time.

regards, tom lane

Re: Naming of gss_accept_deleg

2023-05-22 Thread Abhijit Menon-Sen 
At 2023-05-22 09:42:44 -0400, t...@sss.pgh.pa.us wrote:
>
> Alvaro Herrera  writes:
> > I noticed that the value that enables this feature at libpq client side
> > is 'enable'.  However, for other Boolean settings like sslsni,
> > keepalives, requiressl, sslcompression, the value that enables feature
> > is '1' -- we use strings only for "enum" type of settings.
> 
> > Also, it looks like connectOptions2() doesn't validate the string value.
> 
> Hmm, it certainly seems like this ought to accept exactly the
> same inputs as other libpq boolean settings.  I can take a look
> unless somebody else is already on it.

Here's the diff, but the 0/1 values of settings like sslsni and
sslcompression don't seem to be validated anywhere, unlike the string
options in connectOptions2, so I didn't do anything for gssdelegation.

(I've never run the Kerberos tests before, but I changed one
"gssdelegation=disable" to "gssdelegation=1" and got a test failure, so
they're probably working as expected.)

-- Abhijit
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index e38a7debc3..2225e4e0ef 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -2059,9 +2059,9 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
   

 Forward (delegate) GSS credentials to the server.  The default is
-disable which means credentials will not be forwarded
-to the server.  Set this to enable to have
-credentials forwarded when possible.
+0 which means credentials will not be forwarded
+to the server.  Set this to 1 to have credentials
+forwarded when possible.

   
  
diff --git a/src/interfaces/libpq/fe-auth.c b/src/interfaces/libpq/fe-auth.c
index de0e13e50d..88fd0f3d80 100644
--- a/src/interfaces/libpq/fe-auth.c
+++ b/src/interfaces/libpq/fe-auth.c
@@ -97,7 +97,7 @@ pg_GSS_continue(PGconn *conn, int payloadlen)
 	if (!pg_GSS_have_cred_cache(>gcred))
 		conn->gcred = GSS_C_NO_CREDENTIAL;
 
-	if (conn->gssdelegation && pg_strcasecmp(conn->gssdelegation, "enable") == 0)
+	if (conn->gssdelegation && conn->gssdelegation[0] == '1')
 		gss_flags |= GSS_C_DELEG_FLAG;
 
 	maj_stat = gss_init_sec_context(_stat,
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 786d22a770..a8584d2c68 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -343,8 +343,8 @@ static const internalPQconninfoOption PQconninfoOptions[] = {
 		"GSS-library", "", 7,	/* sizeof("gssapi") == 7 */
 	offsetof(struct pg_conn, gsslib)},
 
-	{"gssdelegation", "PGGSSDELEGATION", NULL, NULL,
-		"GSS-delegation", "", 8,	/* sizeof("disable") == 8 */
+	{"gssdelegation", "PGGSSDELEGATION", "0", NULL,
+		"GSS-delegation", "", 1,
 	offsetof(struct pg_conn, gssdelegation)},
 
 	{"replication", NULL, NULL, NULL,
diff --git a/src/interfaces/libpq/fe-secure-gssapi.c b/src/interfaces/libpq/fe-secure-gssapi.c
index c77d5cfe9f..7e373236e9 100644
--- a/src/interfaces/libpq/fe-secure-gssapi.c
+++ b/src/interfaces/libpq/fe-secure-gssapi.c
@@ -622,7 +622,7 @@ pqsecure_open_gss(PGconn *conn)
 	if (ret != STATUS_OK)
 		return PGRES_POLLING_FAILED;
 
-	if (conn->gssdelegation && pg_strcasecmp(conn->gssdelegation, "enable") == 0)
+	if (conn->gssdelegation && conn->gssdelegation[0] == '1')
 	{
 		/* Acquire credentials if possible */
 		if (conn->gcred == GSS_C_NO_CREDENTIAL)
diff --git a/src/interfaces/libpq/libpq-int.h b/src/interfaces/libpq/libpq-int.h
index f1854f9919..0045f83cbf 100644
--- a/src/interfaces/libpq/libpq-int.h
+++ b/src/interfaces/libpq/libpq-int.h
@@ -404,7 +404,7 @@ struct pg_conn
 	char	   *krbsrvname;		/* Kerberos service name */
 	char	   *gsslib;			/* What GSS library to use ("gssapi" or
  * "sspi") */
-	char	   *gssdelegation;	/* Try to delegate GSS credentials? */
+	char	   *gssdelegation;	/* Try to delegate GSS credentials? (0 or 1) */
 	char	   *ssl_min_protocol_version;	/* minimum TLS protocol version */
 	char	   *ssl_max_protocol_version;	/* maximum TLS protocol version */
 	char	   *target_session_attrs;	/* desired session properties */
diff --git a/src/test/kerberos/t/001_auth.pl b/src/test/kerberos/t/001_auth.pl
index bff26fda0c..0deb9bffc8 100644
--- a/src/test/kerberos/t/001_auth.pl
+++ b/src/test/kerberos/t/001_auth.pl
@@ -381,7 +381,7 @@ test_access(
 	'test1',
 	'SELECT gss_authenticated AND encrypted AND NOT credentials_delegated FROM pg_stat_gssapi WHERE pid = pg_backend_pid();',
 	0,
-	'gssencmode=prefer gssdelegation=enable',
+	'gssencmode=prefer gssdelegation=1',
 	'succeeds with GSS-encrypted access preferred with host hba and credentials not delegated even though asked for (ticket not forwardable)',
 	"connection authenticated: identity=\"test1\@$realm\" method=gss",
 	"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=yes, delegated_credentials=no, principal=test1\@$realm)"
@@ -391,7 +391,7 @@ test_access(

Re: Naming of gss_accept_deleg

2023-05-22 Thread Abhijit Menon-Sen 
At 2023-05-22 09:42:44 -0400, t...@sss.pgh.pa.us wrote:
>
> Alvaro Herrera  writes:
> > I noticed that the value that enables this feature at libpq client side
> > is 'enable'.  However, for other Boolean settings like sslsni,
> > keepalives, requiressl, sslcompression, the value that enables feature
> > is '1' -- we use strings only for "enum" type of settings.
> 
> > Also, it looks like connectOptions2() doesn't validate the string value.
> 
> Hmm, it certainly seems like this ought to accept exactly the
> same inputs as other libpq boolean settings.  I can take a look
> unless somebody else is already on it.

I'm working on it.

-- Abhijit

Re: Naming of gss_accept_deleg

2023-05-22 Thread Tom Lane 
Alvaro Herrera  writes:
> I noticed that the value that enables this feature at libpq client side
> is 'enable'.  However, for other Boolean settings like sslsni,
> keepalives, requiressl, sslcompression, the value that enables feature
> is '1' -- we use strings only for "enum" type of settings.

> Also, it looks like connectOptions2() doesn't validate the string value.

Hmm, it certainly seems like this ought to accept exactly the
same inputs as other libpq boolean settings.  I can take a look
unless somebody else is already on it.

regards, tom lane

Re: Naming of gss_accept_deleg

2023-05-22 Thread Alvaro Herrera 
I noticed that the value that enables this feature at libpq client side
is 'enable'.  However, for other Boolean settings like sslsni,
keepalives, requiressl, sslcompression, the value that enables feature
is '1' -- we use strings only for "enum" type of settings.

Also, it looks like connectOptions2() doesn't validate the string value.

-- 
Álvaro Herrera   48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
 really, I see PHP as like a strange amalgamation of C, Perl, Shell
 inflex: you know that "amalgam" means "mixture with mercury",
   more or less, right?
 i.e., "deadly poison"

Re: Naming of gss_accept_deleg

2023-05-21 Thread Stephen Frost 
Greetings,

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Abhijit Menon-Sen  writes:
> > At 2023-05-20 23:21:57 -0400, t...@sss.pgh.pa.us wrote:
> >> I thought the plan was to also rename the libpq "gssdeleg" connection
> >> parameter and so on?  I can look into that tomorrow, if nobody beats
> >> me to it.
> 
> > I was trying the change to see if it would be better to name it
> > "gssdelegate" instead (as in delegate on one side, and accept the
> > delegation on the other), but decided that "gssdelegation=enable"
> > reads better than "gssdelegate=enable".
> 
> Yeah, agreed.
> 
> > Here's the diff.
> 
> Thanks for doing that legwork!  I found a couple other places where
> "deleg" had escaped notice, and changed the lot.  Watching the
> buildfarm now ...

Thanks all for taking this up over a weekend.

Stephen


signature.asc
Description: PGP signature

Re: Naming of gss_accept_deleg

2023-05-21 Thread Tom Lane 
Abhijit Menon-Sen  writes:
> At 2023-05-20 23:21:57 -0400, t...@sss.pgh.pa.us wrote:
>> I thought the plan was to also rename the libpq "gssdeleg" connection
>> parameter and so on?  I can look into that tomorrow, if nobody beats
>> me to it.

> I was trying the change to see if it would be better to name it
> "gssdelegate" instead (as in delegate on one side, and accept the
> delegation on the other), but decided that "gssdelegation=enable"
> reads better than "gssdelegate=enable".

Yeah, agreed.

> Here's the diff.

Thanks for doing that legwork!  I found a couple other places where
"deleg" had escaped notice, and changed the lot.  Watching the
buildfarm now ...

regards, tom lane

Re: Naming of gss_accept_deleg

2023-05-21 Thread Abhijit Menon-Sen 
At 2023-05-20 23:21:57 -0400, t...@sss.pgh.pa.us wrote:
>
> Nathan Bossart  writes:
> > On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:
> >> With less then 48 hours to beta 1 packaging, I have made this change and
> >> adjusted internal variable to match.
> 
> > The buildfarm and cfbot seem unhappy with 9c0a0e2.  It looks like there are
> > a few remaining uses of gss_accept_deleg to rename.  I'm planning to commit
> > the attached patch shortly.
> 
> I thought the plan was to also rename the libpq "gssdeleg" connection
> parameter and so on?  I can look into that tomorrow, if nobody beats
> me to it.

I was trying the change to see if it would be better to name it
"gssdelegate" instead (as in delegate on one side, and accept the
delegation on the other), but decided that "gssdelegation=enable"
reads better than "gssdelegate=enable".

Here's the diff.

-- Abhijit
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected/postgres_fdw.out
index 826baac9f1..c8c4614b54 100644
--- a/contrib/postgres_fdw/expected/postgres_fdw.out
+++ b/contrib/postgres_fdw/expected/postgres_fdw.out
@@ -172,7 +172,7 @@ ALTER SERVER testserver1 OPTIONS (
 	--requirepeer 'value',
 	krbsrvname 'value',
 	gsslib 'value',
-	gssdeleg 'value'
+	gssdelegation 'value'
 	--replication 'value'
 );
 -- Error, invalid list syntax
diff --git a/contrib/postgres_fdw/option.c b/contrib/postgres_fdw/option.c
index fe40d50c6d..5c301e0ef3 100644
--- a/contrib/postgres_fdw/option.c
+++ b/contrib/postgres_fdw/option.c
@@ -289,10 +289,10 @@ InitPgFdwOptions(void)
 		{"sslkey", UserMappingRelationId, true},
 
 		/*
-		 * gssdeleg is also a libpq option but should be allowed in a user
-		 * mapping context too
+		 * gssdelegation is also a libpq option but should be allowed in
+		 * a user mapping context too
 		 */
-		{"gssdeleg", UserMappingRelationId, true},
+		{"gssdelegation", UserMappingRelationId, true},
 
 		{NULL, InvalidOid, false}
 	};
diff --git a/contrib/postgres_fdw/sql/postgres_fdw.sql b/contrib/postgres_fdw/sql/postgres_fdw.sql
index 15f3af6c29..b54903ad8f 100644
--- a/contrib/postgres_fdw/sql/postgres_fdw.sql
+++ b/contrib/postgres_fdw/sql/postgres_fdw.sql
@@ -186,7 +186,7 @@ ALTER SERVER testserver1 OPTIONS (
 	--requirepeer 'value',
 	krbsrvname 'value',
 	gsslib 'value',
-	gssdeleg 'value'
+	gssdelegation 'value'
 	--replication 'value'
 );
 
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index cce25d06e6..e38a7debc3 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -2054,8 +2054,8 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
   
  
 
- 
-  gssdeleg
+ 
+  gssdelegation
   

 Forward (delegate) GSS credentials to the server.  The default is
@@ -8271,10 +8271,10 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
 
  
   
-   PGGSSDELEG
+   PGGSSDELEGATION
   
-  PGGSSDELEG behaves the same as the  connection parameter.
+  PGGSSDELEGATION behaves the same as the  connection parameter.
  
 
 
diff --git a/src/backend/foreign/foreign.c b/src/backend/foreign/foreign.c
index 6e1977fa62..ca3ad55b62 100644
--- a/src/backend/foreign/foreign.c
+++ b/src/backend/foreign/foreign.c
@@ -574,7 +574,7 @@ static const struct ConnectionOption libpq_conninfo_options[] = {
 	{"requiressl", ForeignServerRelationId},
 	{"sslmode", ForeignServerRelationId},
 	{"gsslib", ForeignServerRelationId},
-	{"gssdeleg", ForeignServerRelationId},
+	{"gssdelegation", ForeignServerRelationId},
 	{NULL, InvalidOid}
 };
 
diff --git a/src/interfaces/libpq/fe-auth.c b/src/interfaces/libpq/fe-auth.c
index 0dc31988b4..de0e13e50d 100644
--- a/src/interfaces/libpq/fe-auth.c
+++ b/src/interfaces/libpq/fe-auth.c
@@ -97,7 +97,7 @@ pg_GSS_continue(PGconn *conn, int payloadlen)
 	if (!pg_GSS_have_cred_cache(>gcred))
 		conn->gcred = GSS_C_NO_CREDENTIAL;
 
-	if (conn->gssdeleg && pg_strcasecmp(conn->gssdeleg, "enable") == 0)
+	if (conn->gssdelegation && pg_strcasecmp(conn->gssdelegation, "enable") == 0)
 		gss_flags |= GSS_C_DELEG_FLAG;
 
 	maj_stat = gss_init_sec_context(_stat,
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 30486c59ba..786d22a770 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -343,9 +343,9 @@ static const internalPQconninfoOption PQconninfoOptions[] = {
 		"GSS-library", "", 7,	/* sizeof("gssapi") == 7 */
 	offsetof(struct pg_conn, gsslib)},
 
-	{"gssdeleg", "PGGSSDELEG", NULL, NULL,
+	{"gssdelegation", "PGGSSDELEGATION", NULL, NULL,
 		"GSS-delegation", "", 8,	/* sizeof("disable") == 8 */
-	offsetof(struct pg_conn, gssdeleg)},
+	offsetof(struct pg_conn, gssdelegation)},
 
 	{"replication", NULL, NULL, NULL,
 		"Replication", "D", 5,
@@ -4453,7 +4453,7 @@ freePGconn(PGconn *conn)
 	free(conn->gssencmode);
 	free(conn->krbsrvname);
 	free(conn->gsslib);
-	free(conn->gssdeleg);
+

Re: Naming of gss_accept_deleg

2023-05-20 Thread Nathan Bossart 
On Sat, May 20, 2023 at 11:21:57PM -0400, Tom Lane wrote:
> Nathan Bossart  writes:
>> The buildfarm and cfbot seem unhappy with 9c0a0e2.  It looks like there are
>> a few remaining uses of gss_accept_deleg to rename.  I'm planning to commit
>> the attached patch shortly.

Done.

> I thought the plan was to also rename the libpq "gssdeleg" connection
> parameter and so on?  I can look into that tomorrow, if nobody beats
> me to it.

Please do.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Re: Naming of gss_accept_deleg

2023-05-20 Thread Bruce Momjian 
On Sat, May 20, 2023 at 11:21:57PM -0400, Tom Lane wrote:
> Nathan Bossart  writes:
> > On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:
> >> With less then 48 hours to beta 1 packaging, I have made this change and
> >> adjusted internal variable to match.
> 
> > The buildfarm and cfbot seem unhappy with 9c0a0e2.  It looks like there are
> > a few remaining uses of gss_accept_deleg to rename.  I'm planning to commit
> > the attached patch shortly.
> 
> I thought the plan was to also rename the libpq "gssdeleg" connection
> parameter and so on?  I can look into that tomorrow, if nobody beats
> me to it.

Oh, I didn't consider those.  I thought we would leave libpq alone since
those are often supplied on the command line and there are existing
short-style libpq options, e.g., gssencmode, krbsrvname, sslcrl.

I am fine with such a change though.

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.

Re: Naming of gss_accept_deleg

2023-05-20 Thread Tom Lane 
Nathan Bossart  writes:
> On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:
>> With less then 48 hours to beta 1 packaging, I have made this change and
>> adjusted internal variable to match.

> The buildfarm and cfbot seem unhappy with 9c0a0e2.  It looks like there are
> a few remaining uses of gss_accept_deleg to rename.  I'm planning to commit
> the attached patch shortly.

I thought the plan was to also rename the libpq "gssdeleg" connection
parameter and so on?  I can look into that tomorrow, if nobody beats
me to it.

regards, tom lane

Re: Naming of gss_accept_deleg

2023-05-20 Thread Bruce Momjian 
On Sat, May 20, 2023 at 08:17:57PM -0700, Nathan Bossart wrote:
> On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:
> > With less then 48 hours to beta 1 packaging, I have made this change and
> > adjusted internal variable to match.
> 
> The buildfarm and cfbot seem unhappy with 9c0a0e2.  It looks like there are
> a few remaining uses of gss_accept_deleg to rename.  I'm planning to commit
> the attached patch shortly.

Yes, please do.  I saw some matches in the tests but was confused since
my tests passed.  I now realize I wasn't testing those.

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.

Re: Naming of gss_accept_deleg

2023-05-20 Thread Nathan Bossart 
On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:
> With less then 48 hours to beta 1 packaging, I have made this change and
> adjusted internal variable to match.

The buildfarm and cfbot seem unhappy with 9c0a0e2.  It looks like there are
a few remaining uses of gss_accept_deleg to rename.  I'm planning to commit
the attached patch shortly.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index c8018da04a..b090ec5245 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -101,7 +101,7 @@
 # GSSAPI using Kerberos
 #krb_server_keyfile = 'FILE:${sysconfdir}/krb5.keytab'
 #krb_caseins_users = off
-#gss_accept_deleg = off
+#gss_accept_delegation = off
 
 # - SSL -
 
diff --git a/src/test/kerberos/t/001_auth.pl b/src/test/kerberos/t/001_auth.pl
index 39c035de32..5aff49a513 100644
--- a/src/test/kerberos/t/001_auth.pl
+++ b/src/test/kerberos/t/001_auth.pl
@@ -496,7 +496,7 @@ test_access(
 	"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=yes, deleg_credentials=no, principal=test1\@$realm)"
 );
 
-$node->append_conf('postgresql.conf', qq{gss_accept_deleg=off});
+$node->append_conf('postgresql.conf', qq{gss_accept_delegation=off});
 $node->restart;
 
 test_access(
@@ -520,7 +520,7 @@ test_access(
 	"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=yes, deleg_credentials=no, principal=test1\@$realm)"
 );
 
-$node->append_conf('postgresql.conf', qq{gss_accept_deleg=on});
+$node->append_conf('postgresql.conf', qq{gss_accept_delegation=on});
 $node->restart;
 
 test_access(

Re: Naming of gss_accept_deleg

2023-05-20 Thread Bruce Momjian 
On Fri, May 19, 2023 at 07:58:34AM -0700, Nathan Bossart wrote:
> On Fri, May 19, 2023 at 09:42:00AM -0400, Tom Lane wrote:
> > Abhijit Menon-Sen  writes:
> >> I would also prefer a GUC named gss_accept_delegation, but the current
> >> name matches the libpq gssdeleg connection parameter and the PGSSDELEG
> >> environment variable. Maybe there's something to be said for keeping
> >> those three things alike?
> > 
> > +1 for spelling it out in all user-visible names.  I do not think
> > that that GSS-API C symbol is a good precedent to follow.
> 
> +1

With less then 48 hours to beta 1 packaging, I have made this change and
adjusted internal variable to match.

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.

Re: Naming of gss_accept_deleg

2023-05-19 Thread Nathan Bossart 
On Fri, May 19, 2023 at 09:42:00AM -0400, Tom Lane wrote:
> Abhijit Menon-Sen  writes:
>> I would also prefer a GUC named gss_accept_delegation, but the current
>> name matches the libpq gssdeleg connection parameter and the PGSSDELEG
>> environment variable. Maybe there's something to be said for keeping
>> those three things alike?
> 
> +1 for spelling it out in all user-visible names.  I do not think
> that that GSS-API C symbol is a good precedent to follow.

+1

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Re: Naming of gss_accept_deleg

2023-05-19 Thread Bruce Momjian 
On Fri, May 19, 2023 at 09:42:00AM -0400, Tom Lane wrote:
> Abhijit Menon-Sen  writes:
> > I would also prefer a GUC named gss_accept_delegation, but the current
> > name matches the libpq gssdeleg connection parameter and the PGSSDELEG
> > environment variable. Maybe there's something to be said for keeping
> > those three things alike?
> 
> +1 for spelling it out in all user-visible names.  I do not think
> that that GSS-API C symbol is a good precedent to follow.

Once nice bonus of the release notes is that it allows us to see the new
API in one place to check for consistency.

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.

Re: Naming of gss_accept_deleg

2023-05-19 Thread Tom Lane 
Abhijit Menon-Sen  writes:
> I would also prefer a GUC named gss_accept_delegation, but the current
> name matches the libpq gssdeleg connection parameter and the PGSSDELEG
> environment variable. Maybe there's something to be said for keeping
> those three things alike?

+1 for spelling it out in all user-visible names.  I do not think
that that GSS-API C symbol is a good precedent to follow.

regards, tom lane

Re: Naming of gss_accept_deleg

2023-05-19 Thread Abhijit Menon-Sen 
At 2023-05-19 09:16:09 -0400, br...@momjian.us wrote:
>
> On Fri, May 19, 2023 at 09:07:26AM -0400, Stephen Frost wrote:
> > 
> > > Why is the new PG 16 GUC called "gss_accept_deleg" and not
> > > "gss_accept_delegation"?  The abbreviation here seems atypical.
> > 
> > At the time it felt natural to me but I don't feel strongly about it,
> > happy to change it if folks would prefer it spelled out.
> 
> Yes, please do spell it out, thanks.  The fact "deleg" looks similar to
> "debug" also doesn't help.

Note that GSS-API itself calls it the "DELEG" flag:

if (conn->gcred != GSS_C_NO_CREDENTIAL)
gss_flags |= GSS_C_DELEG_FLAG;

I would also prefer a GUC named gss_accept_delegation, but the current
name matches the libpq gssdeleg connection parameter and the PGSSDELEG
environment variable. Maybe there's something to be said for keeping
those three things alike?

-- Abhijit

Re: Naming of gss_accept_deleg

2023-05-19 Thread Bruce Momjian 
On Fri, May 19, 2023 at 09:07:26AM -0400, Stephen Frost wrote:
> Greetings,
> 
> * Bruce Momjian (br...@momjian.us) wrote:
> > Why is the new PG 16 GUC called "gss_accept_deleg" and not
> > "gss_accept_delegation"?  The abbreviation here seems atypical.
> 
> At the time it felt natural to me but I don't feel strongly about it,
> happy to change it if folks would prefer it spelled out.

Yes, please do spell it out, thanks.  The fact "deleg" looks similar to
"debug" also doesn't help.

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.

Re: Naming of gss_accept_deleg

2023-05-19 Thread Stephen Frost 
Greetings,

* Bruce Momjian (br...@momjian.us) wrote:
> Why is the new PG 16 GUC called "gss_accept_deleg" and not
> "gss_accept_delegation"?  The abbreviation here seems atypical.

At the time it felt natural to me but I don't feel strongly about it,
happy to change it if folks would prefer it spelled out.

Thanks,

Stephen


signature.asc
Description: PGP signature