public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sebastien Flaesch <[email protected]>
To: Tom Lane <[email protected]>
To: 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 07:17:47 +0000
Message-ID: <DBAP191MB1289417EA192457D9663350EB0D82@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <[email protected]>
References: <PAWPR07MB1009569596278D85AC691BBF4AEDD2@PAWPR07MB10095.eurprd07.prod.outlook.com>
<[email protected]>
<DBAP191MB1289124F5D8690DF3F72F62CB0DC2@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM>
<[email protected]>
<DBAP191MB1289C92E15014C2627C49BEBB0D92@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM>
<[email protected]>
<[email protected]>
Let's not deviate from my request:
I have implemented various DB client modules using the C client APIs, for Oracle DB, SQL Server, IBM DB2, MySQL/MariaDB, SQLite and PostgreSQL.
While I like PostgreSQL a lot, this is the only case where I have to define myself the column type ids, to implement a "describe column" feature.
ODBC has SQLDescribeCol() / SQLDescribeColW() and predefined SQL_* constants like SQL_INTEGER, SQL_VARCHAR ...
Native PostgreSQL built-in SQL types should be listed in a .h header of the C client API
I do not want to execute SQL to identify a column type returned by PQftype().
This is not efficient, even if I would cache the mapping of the type oid to a type name.
I just want to do this:
static int prepareField(SqlStatement *st, int i)
{
int pgftype = PQftype(st->pgResult, i);
int pgfmod = PQfmod(st->pgResult, i);
...
switch (pgftype) {
case PG_TYPE_BOOL:
...
break;
case PG_TYPE_CHAR:
case PG_TYPE_BPCHAR:
case PG_TYPE_VARCHAR:
...
break;
And today I have to define all these type ids:
/* ! Should be provided by a PostgreSQL header file! */
#define PG_TYPE_BOOL 16
#define PG_TYPE_BYTEA 17
#define PG_TYPE_CHAR 18
#define PG_TYPE_NAME 19
#define PG_TYPE_INT8 20
#define PG_TYPE_INT2 21
#define PG_TYPE_INT2VECTOR 22
#define PG_TYPE_INT4 23
#define PG_TYPE_REGPROC 24
#define PG_TYPE_TEXT 25
#define PG_TYPE_OID 26
#define PG_TYPE_TID 27
#define PG_TYPE_XID 28
#define PG_TYPE_CID 29
...
I don't care if this list is generated when building PostgreSQL from sources.
I expect however that the type oids for built-in types remain the same forever.
Seb
________________________________
From: Tom Lane <[email protected]>
Sent: Wednesday, March 19, 2025 6:22 PM
To: Adrian Klaver <[email protected]>
Cc: Sebastien Flaesch <[email protected]>; M Tarkeshwar Rao <[email protected]>; [email protected] <[email protected]>
Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID
EXTERNAL: Do not click links or open attachments if you do not recognize the sender.
Adrian Klaver <[email protected]> writes:
> On 3/18/25 23:41, Sebastien Flaesch wrote:
>> I was not expecting this file to be in a "server" folder, when it's to
>> be used for client apps.
> Not surprising. As I understand it this is the code used to build the
> type entries in the system catalog pg_type.
More the other way around: pg_type_d.h is built from the authoritative
source files pg_type.h and pg_type.dat, according to the process
described here:
https://urldefense.com/v3/__https://www.postgresql.org/docs/devel/bki.html__;!!I_DbfM1H!GM5pJKRPNVAr...
>> And still, I do not trust the content.
Why not? If it's the "Backwards compatibility" comment that's
bothering you, a look at pg_type.h will show you that that's
only intended to apply to the CASHOID and LSNOID symbols.
Everything below that in pg_type_d.h is machine-generated.
regards, tom lane
view thread (17+ 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]
Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID
In-Reply-To: <DBAP191MB1289417EA192457D9663350EB0D82@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM>
* 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