|
Tom,
I don't care about the .h file name or location, what scares me is this:
/*
* Backwards compatibility for ancient random spellings of pg_type OID macros.
* Don't use these names in new code.
*/
#define CASHOID MONEYOID
#define LSNOID PG_LSNOID
#define BOOLOID 16
#define BYTEAOID 17
#define CHAROID 18
#define NAMEOID 19
#define INT8OID 20
#define INT2OID 21
#define INT2VECTOROID 22
#define INT4OID 23
#define REGPROCOID 24
If I am missing something, then please point me to the correct .h file that contains #define constants without this scary comment.
OR.... ( I guess I start to understand the code... ) it this comment only for:
#define CASHOID MONEYOID
#define LSNOID PG_LSNOID
???
And sorry if I consider constant names like these (without any prefix such as PG_TYPE_)
#define BOOLOID 16
#define BYTEAOID 17
#define CHAROID 18
#define NAMEOID 19
#define INT8OID 20
#define INT2OID 21
...
... are looking more like names not to be used!
Arrogance does not help here, clarity and better API doc would.
Seb
From: Tom Lane <tgl@xxxxxxxxxxxxx>
Sent: Thursday, March 20, 2025 3:31 PM To: Sebastien Flaesch <sebastien.flaesch@xxxxxxx> Cc: Adrian Klaver <adrian.klaver@xxxxxxxxxxx>; M Tarkeshwar Rao <m.tarkeshwar.rao@xxxxxxxxxxxx>; pgsql-general@xxxxxxxxxxxxxx <pgsql-general@xxxxxxxxxxxxxx> 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.
Sebastien Flaesch <sebastien.flaesch@xxxxxxx> writes: > Native PostgreSQL built-in SQL types should be listed in a .h header of the C client API They are. You were already pointed to it. The fact that you don't like how that file's name is spelled is not really going to impress anyone. regards, tom lane |
