public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 1/4] bootstrap: convert Typ to a List* 6+ messages / 5 participants [nested] [flat]
* [PATCH 1/4] bootstrap: convert Typ to a List* @ 2020-11-20 02:48 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Justin Pryzby @ 2020-11-20 02:48 UTC (permalink / raw) --- src/backend/bootstrap/bootstrap.c | 89 ++++++++++++++----------------- 1 file changed, 41 insertions(+), 48 deletions(-) diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c index 6f615e6622..1b940d9d27 100644 --- a/src/backend/bootstrap/bootstrap.c +++ b/src/backend/bootstrap/bootstrap.c @@ -58,7 +58,7 @@ static void BootstrapModeMain(void); static void bootstrap_signals(void); static void ShutdownAuxiliaryProcess(int code, Datum arg); static Form_pg_attribute AllocateAttribute(void); -static void populate_typ_array(void); +static void populate_typ(void); static Oid gettype(char *type); static void cleanup(void); @@ -159,7 +159,7 @@ struct typmap FormData_pg_type am_typ; }; -static struct typmap **Typ = NULL; +static List *Typ = NIL; /* List of struct typmap* */ static struct typmap *Ap = NULL; static Datum values[MAXATTR]; /* current row's attribute values */ @@ -595,10 +595,10 @@ boot_openrel(char *relname) /* * pg_type must be filled before any OPEN command is executed, hence we - * can now populate the Typ array if we haven't yet. + * can now populate Typ if we haven't yet. */ - if (Typ == NULL) - populate_typ_array(); + if (Typ == NIL) + populate_typ(); if (boot_reldesc != NULL) closerel(NULL); @@ -688,7 +688,7 @@ DefineAttr(char *name, char *type, int attnum, int nullness) typeoid = gettype(type); - if (Typ != NULL) + if (Typ != NIL) { attrtypes[attnum]->atttypid = Ap->am_oid; attrtypes[attnum]->attlen = Ap->am_typ.typlen; @@ -866,47 +866,36 @@ cleanup(void) } /* ---------------- - * populate_typ_array + * populate_typ * - * Load the Typ array by reading pg_type. + * Load Typ by reading pg_type. * ---------------- */ static void -populate_typ_array(void) +populate_typ(void) { Relation rel; TableScanDesc scan; HeapTuple tup; - int nalloc; - int i; - - Assert(Typ == NULL); + MemoryContext old; - nalloc = 512; - Typ = (struct typmap **) - MemoryContextAlloc(TopMemoryContext, nalloc * sizeof(struct typmap *)); + Assert(Typ == NIL); rel = table_open(TypeRelationId, NoLock); scan = table_beginscan_catalog(rel, 0, NULL); - i = 0; + old = MemoryContextSwitchTo(TopMemoryContext); while ((tup = heap_getnext(scan, ForwardScanDirection)) != NULL) { Form_pg_type typForm = (Form_pg_type) GETSTRUCT(tup); + struct typmap *newtyp; - /* make sure there will be room for a trailing NULL pointer */ - if (i >= nalloc - 1) - { - nalloc *= 2; - Typ = (struct typmap **) - repalloc(Typ, nalloc * sizeof(struct typmap *)); - } - Typ[i] = (struct typmap *) - MemoryContextAlloc(TopMemoryContext, sizeof(struct typmap)); - Typ[i]->am_oid = typForm->oid; - memcpy(&(Typ[i]->am_typ), typForm, sizeof(Typ[i]->am_typ)); - i++; + newtyp = (struct typmap *) palloc(sizeof(struct typmap)); + Typ = lappend(Typ, newtyp); + + newtyp->am_oid = typForm->oid; + memcpy(&newtyp->am_typ, typForm, sizeof(newtyp->am_typ)); } - Typ[i] = NULL; /* Fill trailing NULL pointer */ + MemoryContextSwitchTo(old); table_endscan(scan); table_close(rel, NoLock); } @@ -916,25 +905,26 @@ populate_typ_array(void) * * NB: this is really ugly; it will return an integer index into TypInfo[], * and not an OID at all, until the first reference to a type not known in - * TypInfo[]. At that point it will read and cache pg_type in the Typ array, + * TypInfo[]. At that point it will read and cache pg_type in Typ, * and subsequently return a real OID (and set the global pointer Ap to * point at the found row in Typ). So caller must check whether Typ is - * still NULL to determine what the return value is! + * still NIL to determine what the return value is! * ---------------- */ static Oid gettype(char *type) { - if (Typ != NULL) + if (Typ != NIL) { - struct typmap **app; + ListCell *lc; - for (app = Typ; *app != NULL; app++) + foreach (lc, Typ) { - if (strncmp(NameStr((*app)->am_typ.typname), type, NAMEDATALEN) == 0) + struct typmap *app = lfirst(lc); + if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0) { - Ap = *app; - return (*app)->am_oid; + Ap = app; + return app->am_oid; } } } @@ -949,7 +939,7 @@ gettype(char *type) } /* Not in TypInfo, so we'd better be able to read pg_type now */ elog(DEBUG4, "external type: %s", type); - populate_typ_array(); + populate_typ(); return gettype(type); } elog(ERROR, "unrecognized type \"%s\"", type); @@ -977,17 +967,20 @@ boot_get_type_io_data(Oid typid, Oid *typinput, Oid *typoutput) { - if (Typ != NULL) + if (Typ != NIL) { /* We have the boot-time contents of pg_type, so use it */ - struct typmap **app; - struct typmap *ap; - - app = Typ; - while (*app && (*app)->am_oid != typid) - ++app; - ap = *app; - if (ap == NULL) + struct typmap *ap = NULL; + ListCell *lc; + + foreach (lc, Typ) + { + ap = lfirst(lc); + if (ap->am_oid == typid) + break; + } + + if (!ap || ap->am_oid != typid) elog(ERROR, "type OID %u not found in Typ list", typid); *typlen = ap->am_typ.typlen; -- 2.26.2 --------------BCA1373AE29B32B57608F4EE Content-Type: text/x-patch; charset=UTF-8; name="0002-Allow-composite-types-in-bootstrap-20210307.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0002-Allow-composite-types-in-bootstrap-20210307.patch" ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Remove MSVC scripts from the tree @ 2023-09-26 05:25 NINGWEI CHEN <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: NINGWEI CHEN @ 2023-09-26 05:25 UTC (permalink / raw) To: Michael Paquier <[email protected]>; [email protected]; +Cc: [email protected] On Fri, 22 Sep 2023 10:12:29 +0900 Michael Paquier <[email protected]> wrote: > As of today, I can see that the only buildfarm members relying on > these scripts are bowerbird and hamerkop, so these two would fail if > the patch attached were to be applied today. I am adding Andrew > D. and the maintainers of hamerkop (SRA-OSS) in CC for comments. hamerkop is not yet prepared for Meson builds, but we plan to work on this support soon. If we go with Meson builds exclusively right now, we will have to temporarily remove the master/HEAD for a while. Best Regards. -- SRA OSS LLC Chen Ningwei<[email protected]> ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Remove MSVC scripts from the tree @ 2023-09-26 16:17 Andrew Dunstan <[email protected]> parent: NINGWEI CHEN <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Andrew Dunstan @ 2023-09-26 16:17 UTC (permalink / raw) To: NINGWEI CHEN <[email protected]>; Michael Paquier <[email protected]>; [email protected]; +Cc: [email protected] On 2023-09-26 Tu 01:25, NINGWEI CHEN wrote: > On Fri, 22 Sep 2023 10:12:29 +0900 > Michael Paquier<[email protected]> wrote: > >> As of today, I can see that the only buildfarm members relying on >> these scripts are bowerbird and hamerkop, so these two would fail if >> the patch attached were to be applied today. I am adding Andrew >> D. and the maintainers of hamerkop (SRA-OSS) in CC for comments. > hamerkop is not yet prepared for Meson builds, but we plan to work on this support soon. > If we go with Meson builds exclusively right now, we will have to temporarily remove the master/HEAD for a while. > > Best Regards. I don't think we should switch to that until you're ready. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Remove MSVC scripts from the tree @ 2023-12-04 08:05 Michael Paquier <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Michael Paquier @ 2023-12-04 08:05 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: NINGWEI CHEN <[email protected]>; [email protected]; [email protected] On Tue, Sep 26, 2023 at 12:17:04PM -0400, Andrew Dunstan wrote: > On 2023-09-26 Tu 01:25, NINGWEI CHEN wrote: >> hamerkop is not yet prepared for Meson builds, but we plan to work on this support soon. >> If we go with Meson builds exclusively right now, we will have to temporarily remove the master/HEAD for a while. > > I don't think we should switch to that until you're ready. Agreed that it would just be breaking a build for the sake of breaking it. Saying that, the last exchange that we had about hamerkop switching to meson was two months ago. Are there any plans to do the switch? -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Remove MSVC scripts from the tree @ 2023-12-04 20:11 Andrew Dunstan <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Andrew Dunstan @ 2023-12-04 20:11 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: NINGWEI CHEN <[email protected]>; [email protected]; [email protected] On 2023-12-04 Mo 03:05, Michael Paquier wrote: > On Tue, Sep 26, 2023 at 12:17:04PM -0400, Andrew Dunstan wrote: >> On 2023-09-26 Tu 01:25, NINGWEI CHEN wrote: >>> hamerkop is not yet prepared for Meson builds, but we plan to work on this support soon. >>> If we go with Meson builds exclusively right now, we will have to temporarily remove the master/HEAD for a while. >> I don't think we should switch to that until you're ready. > Agreed that it would just be breaking a build for the sake of breaking > it. Saying that, the last exchange that we had about hamerkop > switching to meson was two months ago. Are there any plans to do the > switch? I just had a look at shifting bowerbird to use meson, and it got stymied at the c99 test, which apparently doesn't compile with anything less than VS2019. I can upgrade bowerbird, but that will take rather longer. It looks like hamerkop is in th4e same boat. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Remove MSVC scripts from the tree @ 2023-12-07 17:05 Andres Freund <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Andres Freund @ 2023-12-07 17:05 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; NINGWEI CHEN <[email protected]>; [email protected]; [email protected] Hi, On 2023-12-04 15:11:47 -0500, Andrew Dunstan wrote: > I just had a look at shifting bowerbird to use meson, and it got stymied at > the c99 test, which apparently doesn't compile with anything less than > VS2019. What error or warning is being raised by msvc? Andres ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2023-12-07 17:05 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-20 02:48 [PATCH 1/4] bootstrap: convert Typ to a List* Justin Pryzby <[email protected]> 2023-09-26 05:25 Re: Remove MSVC scripts from the tree NINGWEI CHEN <[email protected]> 2023-09-26 16:17 ` Re: Remove MSVC scripts from the tree Andrew Dunstan <[email protected]> 2023-12-04 08:05 ` Re: Remove MSVC scripts from the tree Michael Paquier <[email protected]> 2023-12-04 20:11 ` Re: Remove MSVC scripts from the tree Andrew Dunstan <[email protected]> 2023-12-07 17:05 ` Re: Remove MSVC scripts from the tree Andres Freund <[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