public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: David G. Johnston <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: Sebastien Flaesch <[email protected]>
Cc: Adrian Klaver <[email protected]>
Cc: M Tarkeshwar Rao <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID
Date: Thu, 20 Mar 2025 17:56:05 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKFQuwZYCktj5Ect4f5Mx1OejCRbQ+MoKWQN+F=2Oid5M=3E7Q@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CAKFQuwZYCktj5Ect4f5Mx1OejCRbQ+MoKWQN+F=2Oid5M=3E7Q@mail.gmail.com>
"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 */
view thread (3+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox