Postgres Pro
Downloads
Home   >   mailing lists

Re: After upgrading libpq, the same function(PQftype) call returns a different OID - Mailing list pgsql-general

From Sebastien Flaesch
Subject Re: After upgrading libpq, the same function(PQftype) call returns a different OID
Date
Msg-id DBAP191MB1289417EA192457D9663350EB0D82@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: After upgrading libpq, the same function(PQftype) call returns a different OID  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: After upgrading libpq, the same function(PQftype) call returns a different OID
Re: After upgrading libpq, the same function(PQftype) call returns a different OID
Re: After upgrading libpq, the same function(PQftype) call returns a different OID
List pgsql-general
Tree view
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 <tgl@sss.pgh.pa.us>
Sent: Wednesday, March 19, 2025 6:22 PM
To: Adrian Klaver <adrian.klaver@aklaver.com>
Cc: Sebastien Flaesch <sebastien.flaesch@4js.com>; M Tarkeshwar Rao <m.tarkeshwar.rao@ericsson.com>; pgsql-general@postgresql.org <pgsql-general@postgresql.org>
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 <adrian.klaver@aklaver.com> 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!GM5pJKRPNVArTRiyYGhyIZrVAgLo7RZl1FSS5kG4IZvWLW75bP4zu1P7yVuLucHd3_FbuKym1-W3Wv0iEs6X$

>> 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

pgsql-general by date:

Previous
From: Puspendu Panda
Date:
Subject: Postgres incremental database updates thru CI/CD
Next
From: Luca Ferrari
Date:
Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID