public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 2/3] Allow composite types in bootstrap 4+ messages / 3 participants [nested] [flat]
* [PATCH 2/3] Allow composite types in bootstrap @ 2020-11-17 15:28 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 4+ 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 18eb62ca47..e4fc75ab84 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 the array. + */ + + /* + * 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 = NULL; + populate_typ_array(); + + /* 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 --------------76B8D0DC8AE327D516738282 Content-Type: text/x-patch; charset=UTF-8; name="0003-Extended-statistics-on-expressions-20210108.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0003-Extended-statistics-on-expressions-20210108.patch" ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t @ 2026-01-16 04:01 Tom Lane <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Tom Lane @ 2026-01-16 04:01 UTC (permalink / raw) To: 洪伊 <[email protected]>; +Cc: pgsql-hackers =?UTF-8?B?5rSq5LyK?= <[email protected]> writes: > This patch fix can not build plpython for free-thread python like > python3.14t We've gone to fairly considerable trouble to switch to using Python's limited API, for reasons described here: https://www.postgresql.org/message-id/[email protected] I don't see why we should abandon that for the convenience of somebody's evidently-nonstandard Python build. The proposed patch also breaks the header isolation that the separate plpython_system.h header is meant to maintain. Arguably we should have #define'd Py_LIMITED_API inside plpython_system.h, not where it is. But I don't feel a need to mess with that without a far better argument for why we should change this at all. regards, tom lane ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t @ 2026-01-16 04:33 洪伊 <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: 洪伊 @ 2026-01-16 04:33 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: pgsql-hackers Hi I understand the reason for using Py_LIMITED_API, and python 3.14t is a standard build from cpython team. link: https://docs.python.org/3/whatsnew/3.14.html#whatsnew314-free-threaded-now-supported It seems the only way to build plpython for free-thread python is to use Py_LIMITED_API, otherwise it fails to build. Thanks Hong Yi On Fri, Jan 16, 2026 at 12:01 PM Tom Lane <[email protected]> wrote: > =?UTF-8?B?5rSq5LyK?= <[email protected]> writes: > > This patch fix can not build plpython for free-thread python like > > python3.14t > > We've gone to fairly considerable trouble to switch to using Python's > limited API, for reasons described here: > > > https://www.postgresql.org/message-id/[email protected] > > I don't see why we should abandon that for the convenience of > somebody's evidently-nonstandard Python build. > > The proposed patch also breaks the header isolation that > the separate plpython_system.h header is meant to maintain. > Arguably we should have #define'd Py_LIMITED_API inside > plpython_system.h, not where it is. But I don't feel a need > to mess with that without a far better argument for why > we should change this at all. > > regards, tom lane > ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t @ 2026-01-16 04:43 Tom Lane <[email protected]> parent: 洪伊 <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Tom Lane @ 2026-01-16 04:43 UTC (permalink / raw) To: 洪伊 <[email protected]>; +Cc: pgsql-hackers =?UTF-8?B?5rSq5LyK?= <[email protected]> writes: > I understand the reason for using Py_LIMITED_API, and python 3.14t is a > standard build from cpython team. AIUI, the "limited API" was devised by the Python community as an API/ABI subset that they are prepared to guarantee holds stable for every Python 3.x release, full stop. I think you're going to have a hard time convincing us that there is anything standard about a Python variant that can't handle client code built against that API. regards, tom lane ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-01-16 04:43 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-17 15:28 [PATCH 2/3] Allow composite types in bootstrap Justin Pryzby <[email protected]> 2026-01-16 04:01 Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t Tom Lane <[email protected]> 2026-01-16 04:33 ` Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t 洪伊 <[email protected]> 2026-01-16 04:43 ` Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t Tom Lane <[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