public inbox for [email protected]help / color / mirror / Atom feed
Re: After upgrading libpq, the same function(PQftype) call returns a different OID 3+ messages / 2 participants [nested] [flat]
* Re: After upgrading libpq, the same function(PQftype) call returns a different OID @ 2025-03-20 21:56 Tom Lane <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2025-03-20 21:56 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; Sebastien Flaesch <[email protected]>; Adrian Klaver <[email protected]>; M Tarkeshwar Rao <[email protected]>; pgsql-general "David G. Johnston" <[email protected]> writes: > On Thu, Mar 20, 2025 at 11:54 AM Tom Lane <[email protected]> wrote: >> I think it's a mistake to suppose that pg_type_d.h is the only >> place where there's a risk of confusion. We should be thinking >> about this more generally: genbki.pl is taking zero thought to >> make what it emits readable. I think it would help to >> label the sections it emits, perhaps along the lines of >> /* Auto-generated OID macros */ > I'd consider this enough for the moment, so long as we explicitly address > the cross-version constancy of the OID values associated with each type. That's documented elsewhere, I believe. For the foo_d.h files, I think it'd be sufficient to do something like 0001 attached. Also, while checking out the results, I noticed that pg_class.h has an "extern" in the wrong place: it's exposed to client code which can have no use for it. That extern doesn't mention any backend-only typedefs, so it's fairly harmless, but it's still a clear example of somebody not reading the memo. Hence 0002. > I'm not going to dive deep enough to make more targeted suggestions. It > does seem, though, that "client code" would seem mostly interested in these > OIDs and not stuff like the attribute numbers of the columns in pg_type. I > get a distinct feel of one file serving multiple use cases. Well, yes it does, but that doesn't make those symbols useless to client code. regards, tom lane Attachments: [text/x-diff] 0001-label-sections-of-_d.h-files.patch (989B, 2-0001-label-sections-of-_d.h-files.patch) download | inline diff: diff --git a/src/backend/catalog/genbki.pl b/src/backend/catalog/genbki.pl index 2501307c92e..df3231fcd41 100644 --- a/src/backend/catalog/genbki.pl +++ b/src/backend/catalog/genbki.pl @@ -480,6 +480,8 @@ foreach my $catname (@catnames) EOM + printf $def "/* Macros related to the structure of $catname */\n\n"; + # Emit OID macros for catalog's OID and rowtype OID, if wanted printf $def "#define %s %s\n", $catalog->{relation_oid_macro}, $catalog->{relation_oid} @@ -561,6 +563,7 @@ EOM print $def "\n#define Natts_$catname $attnum\n\n"; # Emit client code copied from source header + printf $def "/* Definitions copied from ${catname}.h */\n\n"; foreach my $line (@{ $catalog->{client_code} }) { print $def $line; @@ -573,6 +576,9 @@ EOM print $bki "open $catname\n"; } + printf $def + "\n/* OID symbols for objects defined in ${catname}.dat */\n\n"; + # For pg_attribute.h, we generate data entries ourselves. if ($catname eq 'pg_attribute') { [text/x-diff] 0002-place-extern-decl-correctly.patch (541B, 3-0002-place-extern-decl-correctly.patch) download | inline diff: diff --git a/src/include/catalog/pg_class.h b/src/include/catalog/pg_class.h index fa96ba07bf4..07d182da796 100644 --- a/src/include/catalog/pg_class.h +++ b/src/include/catalog/pg_class.h @@ -231,8 +231,8 @@ MAKE_SYSCACHE(RELNAMENSP, pg_class_relname_nsp_index, 128); (relkind) == RELKIND_TOASTVALUE || \ (relkind) == RELKIND_MATVIEW) -extern int errdetail_relkind_not_supported(char relkind); - #endif /* EXPOSE_TO_CLIENT_CODE */ +extern int errdetail_relkind_not_supported(char relkind); + #endif /* PG_CLASS_H */ ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: After upgrading libpq, the same function(PQftype) call returns a different OID @ 2025-03-21 15:14 David G. Johnston <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: David G. Johnston @ 2025-03-21 15:14 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; Sebastien Flaesch <[email protected]>; Adrian Klaver <[email protected]>; M Tarkeshwar Rao <[email protected]>; pgsql-general On Thu, Mar 20, 2025 at 2:56 PM Tom Lane <[email protected]> wrote: > "David G. Johnston" <[email protected]> writes: > > On Thu, Mar 20, 2025 at 11:54 AM Tom Lane <[email protected]> wrote: > >> I think it's a mistake to suppose that pg_type_d.h is the only > >> place where there's a risk of confusion. We should be thinking > >> about this more generally: genbki.pl is taking zero thought to > >> make what it emits readable. I think it would help to > >> label the sections it emits, perhaps along the lines of > >> /* Auto-generated OID macros */ > > > I'd consider this enough for the moment, so long as we explicitly address > > the cross-version constancy of the OID values associated with each type. > > That's documented elsewhere, I believe. For the foo_d.h files, > I think it'd be sufficient to do something like 0001 attached. > > WFM. Thanks. Also, while checking out the results, I noticed that pg_class.h > has an "extern" in the wrong place: it's exposed to client code > which can have no use for it. That extern doesn't mention any > backend-only typedefs, so it's fairly harmless, but it's still > a clear example of somebody not reading the memo. Hence 0002. > > Maybe tack this onto genbki.h? diff --git a/src/include/catalog/genbki.h b/src/include/catalog/genbki.h index 26e205529d..4a1567a46b 100644 --- a/src/include/catalog/genbki.h +++ b/src/include/catalog/genbki.h @@ -146,4 +146,6 @@ */ #undef EXPOSE_TO_CLIENT_CODE +/* Additional backend-only code is placed after the client-code section. */ + #endif /* GENBKI_H */ David J. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: After upgrading libpq, the same function(PQftype) call returns a different OID @ 2025-03-21 18:56 Tom Lane <[email protected]> parent: David G. Johnston <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tom Lane @ 2025-03-21 18:56 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; Sebastien Flaesch <[email protected]>; Adrian Klaver <[email protected]>; M Tarkeshwar Rao <[email protected]>; pgsql-general "David G. Johnston" <[email protected]> writes: > On Thu, Mar 20, 2025 at 2:56 PM Tom Lane <[email protected]> wrote: >> That's documented elsewhere, I believe. For the foo_d.h files, >> I think it'd be sufficient to do something like 0001 attached. > WFM. Thanks. Thanks for looking at it. >> Also, while checking out the results, I noticed that pg_class.h >> has an "extern" in the wrong place: it's exposed to client code >> which can have no use for it. That extern doesn't mention any >> backend-only typedefs, so it's fairly harmless, but it's still >> a clear example of somebody not reading the memo. Hence 0002. > Maybe tack this onto genbki.h? > diff --git a/src/include/catalog/genbki.h b/src/include/catalog/genbki.h > index 26e205529d..4a1567a46b 100644 > --- a/src/include/catalog/genbki.h > +++ b/src/include/catalog/genbki.h > @@ -146,4 +146,6 @@ > */ > #undef EXPOSE_TO_CLIENT_CODE > +/* Additional backend-only code is placed after the client-code section. */ > + > #endif /* GENBKI_H */ Doubt that would help ... regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-03-21 18:56 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-03-20 21:56 Re: After upgrading libpq, the same function(PQftype) call returns a different OID Tom Lane <[email protected]> 2025-03-21 15:14 ` David G. Johnston <[email protected]> 2025-03-21 18:56 ` 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