Thread: Exporting type OID macros in a cleaner fashion

Exporting type OID macros in a cleaner fashion

From

Tom Lane

Date:

17 June 2006, 02:58:13

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

Re: Exporting type OID macros in a cleaner fashion

From

Martijn van Oosterhout

Date:

17 June 2006, 22:18:34

On Fri, Jun 16, 2006 at 10:58:05PM -0400, Tom Lane wrote:
> 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.

This is a good idea. It would be nice to be able to have stuff useful
for the frontend available without having to pullin everything for the
backend.

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

At first glance I'd get include/catalog to build it and install it.
pgtypeoids.h sounds like a good name to me and it should be in the top
level.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Re: Exporting type OID macros in a cleaner fashion

From

"Greg Sabino Mullane"

Date:

24 June 2006, 15:54:48

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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

FWIW, that's exactly what we currently do in DBD::Pg to generate an up to
date list of types:

## $file = "pg_type.h"
open(F, $file) or die qq{Could not open file "$file": $!\n};
my %oid;
my $maxlen = 1;
while(<F>) {   next unless /^#define\s+([A-Z0-9_]*OID)\s+(\d+)/o;   $oid{$1} = $2;   length($1) > $maxlen and $maxlen =
length($1);
}
close(F);

We actually go on from there to build a bunch of custom C structs. The maxlen
is simply there to make our final "types.c" line up pretty.

Installing it at the top-level sounds good, although I don't think
we'd see a need to switch to it since we already parse pg_types.h ourselves. ;)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200606241151
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFEnWAfvJuQZxSWSsgRAjgqAKClEDrahFG5NCSrK47Ae7P13QCD+ACg1KHe
XS2uYrmI5wf6i8Mpttpi1U8=
=wlUx
-----END PGP SIGNATURE-----