Exporting type OID macros in a cleaner fashion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Cc: Andrew Vick <avick(at)remote-print(dot)com>
Subject: Exporting type OID macros in a cleaner fashion
Date: 2006-06-17 02:58:05
Message-ID: 10408.1150513085@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This thread:
http://archives.postgresql.org/pgsql-ports/2006-06/msg00005.php
points up that if a client program would like to refer to datatype
OIDs by means of the pg_type.h macros (ie, write "INT4OID" and not
"23"), it's currently forced to include postgres.h, which is not
a good idea for a number of reasons. We intend postgres.h for use
by backend-side code; frontend code ought to use postgres_fe.h, and
indeed a plain libpq client shouldn't be including either. There's
way too much pollution of the client namespace from either file.

I ran into this same problem last week when I wanted to clean up
some hard-coded OIDs in psql's print.c. I did the same thing the
Qt people did, ie, #include postgres.h, but it's a really ugly hack.

I think it'd be a good idea to fix things so that the type OID macros
are available to frontend code without having to break any rules about
what to include. I looked at whether we could sanitize
catalog/pg_type.h so it could be used in a frontend environment, but
there are a couple obstacles there:

* We'd have to move the extern declarations for catalog/pg_type.c
somewhere else, and there's not an obvious candidate.

* There are still the BKI macros (CATALOG, DATA, etc) which really
should not be exported to client code ... DATA in particular seems like
a pretty obtrusive choice of macro name.

The alternative I'm currently thinking about is to build and install an
auto-generated file comparable to fmgroids.h, containing *only* the type
OID macro #defines extracted from pg_type.h. This would require just a
trivial amount of sed hacking.

I'm not entirely clear where to install such a thing though. The
fmgroids.h precedent suggests server/utils/fmgroids.h, but if this is
intended for client-side use it shouldn't go under /server. I'm
tempted to install it as "pgtypeoids.h" at the top level of the
installation include directory ... but then I'm not clear which source
directory ought to generate it.

Thoughts, objections, better ideas?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-17 04:05:31 Re: further meta-data in pg_stat_activity?
Previous Message Tom Lane 2006-06-17 02:34:15 Re: Sun Donated a Sun Fire T2000 to the PostgreSQL