public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 2/4] Allow composite types in bootstrap
6+ messages / 5 participants
[nested] [flat]
* [PATCH 2/4] Allow composite types in bootstrap
@ 2020-11-17 15:28 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Justin Pryzby @ 2020-11-17 15:28 UTC (permalink / raw)
---
src/backend/bootstrap/bootstrap.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c
index 1b940d9d27..a0fcbb3d83 100644
--- a/src/backend/bootstrap/bootstrap.c
+++ b/src/backend/bootstrap/bootstrap.c
@@ -916,6 +916,7 @@ gettype(char *type)
{
if (Typ != NIL)
{
+ static bool did_reread PG_USED_FOR_ASSERTS_ONLY = false; /* Already reread pg_types? */
ListCell *lc;
foreach (lc, Typ)
@@ -927,6 +928,33 @@ gettype(char *type)
return app->am_oid;
}
}
+
+ /*
+ * The type wasn't known; check again to handle composite
+ * types, added since first populating Typ.
+ */
+
+ /*
+ * Once all the types are populated and we handled composite
+ * types, shouldn't need to do that again.
+ */
+ Assert(!did_reread);
+ did_reread = true;
+
+ list_free_deep(Typ);
+ Typ = NIL;
+ populate_typ();
+
+ /* Need to avoid infinite recursion... */
+ foreach (lc, Typ)
+ {
+ struct typmap *app = lfirst(lc);
+ if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0)
+ {
+ Ap = app;
+ return app->am_oid;
+ }
+ }
}
else
{
--
2.26.2
--------------BCA1373AE29B32B57608F4EE
Content-Type: text/x-patch; charset=UTF-8;
name="0003-Use-correct-statistics-kind-in-a-couple-pla-20210307.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0003-Use-correct-statistics-kind-in-a-couple-pla-20210307.pa";
filename*1="tch"
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Naming of gss_accept_deleg
@ 2023-05-19 13:07 Stephen Frost <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Frost @ 2023-05-19 13:07 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: pgsql-hackers
Greetings,
* Bruce Momjian ([email protected]) 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
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Naming of gss_accept_deleg
@ 2023-05-19 13:16 Bruce Momjian <[email protected]>
parent: Stephen Frost <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Momjian @ 2023-05-19 13:16 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: pgsql-hackers
On Fri, May 19, 2023 at 09:07:26AM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian ([email protected]) 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 <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Naming of gss_accept_deleg
@ 2023-05-19 13:35 Abhijit Menon-Sen <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Abhijit Menon-Sen @ 2023-05-19 13:35 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Stephen Frost <[email protected]>; pgsql-hackers
At 2023-05-19 09:16:09 -0400, [email protected] 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Naming of gss_accept_deleg
@ 2023-05-19 13:42 Tom Lane <[email protected]>
parent: Abhijit Menon-Sen <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Tom Lane @ 2023-05-19 13:42 UTC (permalink / raw)
To: Abhijit Menon-Sen <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Stephen Frost <[email protected]>; pgsql-hackers
Abhijit Menon-Sen <[email protected]> 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Naming of gss_accept_deleg
@ 2023-05-19 13:44 Bruce Momjian <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Bruce Momjian @ 2023-05-19 13:44 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Abhijit Menon-Sen <[email protected]>; Stephen Frost <[email protected]>; pgsql-hackers
On Fri, May 19, 2023 at 09:42:00AM -0400, Tom Lane wrote:
> Abhijit Menon-Sen <[email protected]> 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 <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2023-05-19 13:44 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-11-17 15:28 [PATCH 2/4] Allow composite types in bootstrap Justin Pryzby <[email protected]>
2023-05-19 13:07 Re: Naming of gss_accept_deleg Stephen Frost <[email protected]>
2023-05-19 13:16 ` Re: Naming of gss_accept_deleg Bruce Momjian <[email protected]>
2023-05-19 13:35 ` Re: Naming of gss_accept_deleg Abhijit Menon-Sen <[email protected]>
2023-05-19 13:42 ` Re: Naming of gss_accept_deleg Tom Lane <[email protected]>
2023-05-19 13:44 ` Re: Naming of gss_accept_deleg Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox