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 <t...@sss.pgh.pa.us> Sent: Wednesday, March 19, 2025 6:22 PM To: Adrian Klaver <adrian.kla...@aklaver.com> Cc: Sebastien Flaesch <sebastien.flae...@4js.com>; M Tarkeshwar Rao <m.tarkeshwar....@ericsson.com>; pgsql-gene...@postgresql.org <pgsql-gene...@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.kla...@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