INT2OID, etc.

I am enhancing my PyGreSQL 2.0 package and I wanted to determine the
types of returned fields. I tried using the manifest constans
INT2OID, INT4OID, FLOAT4OID, etc but these are defined in the
file src/include/catalog/pg_type.h which doesn't get installed
into the public include directory. Am I right in assuming that
external programs shouldn't use these values? Is there another
way to get what I want? Is it considered acceptable for interface
programs to use this header file? Inquiring minds want to know.

I will say that pg_dump does use it, but it is not really a 3rd party
library.

I recommend you use the file, and make them supply the pgsql source
directory as part of the compile, that way, you can access the files you
need directly. You can do a lookup in pg_type for the names of the
types you want. Maybe you can even write a little psql script to
extract the oid's you need from pg_type, convert the output to #defines,
and #include that in your compile.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

D'Arcy J.M. Cain wrote:

I am enhancing my PyGreSQL 2.0 package and I wanted to determine the
types of returned fields. I tried using the manifest constans
INT2OID, INT4OID, FLOAT4OID, etc but these are defined in the
file src/include/catalog/pg_type.h which doesn't get installed
into the public include directory. Am I right in assuming that
external programs shouldn't use these values? Is there another
way to get what I want? Is it considered acceptable for interface
programs to use this header file? Inquiring minds want to know.

On the one hand, client applications/interfaces shouldn't use
server internal constants like these but query database to get
type' name using type OIDs (like pg_dump does for \d-s).

On the other hand - performance! And ability to use constants
for built-in types is good thing.

I like second way (and so - we should copy pg_type to ~pgsql/include or
something like this) but it would be nice if you support more
general 1st way too.

Vadim

Can we have all the constants put in pg_type? In the implementation
of my perl PL language, some types I care about aren't defined so I
must define them myself, which seems dangerous (should they ever
change)

On Fri, 27 February 1998, at 12:15:21, Vadim B. Mikheev wrote:

Brett McCormick wrote:

Can we have all the constants put in pg_type? In the implementation
of my perl PL language, some types I care about aren't defined so I
must define them myself, which seems dangerous (should they ever
change)

On Fri, 27 February 1998, at 12:15:21, Vadim B. Mikheev wrote:

I like second way (and so - we should copy pg_type to ~pgsql/include or
something like this) but it would be nice if you support more
general 1st way too.

We should do this.

Vadim

Thus spake Bruce Momjian

I will say that pg_dump does use it, but it is not really a 3rd party
library.

Maybe everything in src/interfaces should be considered the same way.

I recommend you use the file, and make them supply the pgsql source
directory as part of the compile, that way, you can access the files you
need directly. You can do a lookup in pg_type for the names of the
types you want. Maybe you can even write a little psql script to
extract the oid's you need from pg_type, convert the output to #defines,
and #include that in your compile.

That's a thought. I just pulled the defines I needed out with many
comments about what a bad boy I was for doing that. I'll look at
something like that.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Thus spake Vadim B. Mikheev

On the one hand, client applications/interfaces shouldn't use
server internal constants like these but query database to get
type' name using type OIDs (like pg_dump does for \d-s).

On the other hand - performance! And ability to use constants
for built-in types is good thing.

I like second way (and so - we should copy pg_type to ~pgsql/include or
something like this) but it would be nice if you support more
general 1st way too.

I think I'll write a program to extract this info and create a header
file. Perhaps that program can be dropped into the distribution.
The only problem is that it has to be run after the system has been
built, installed and initialized so it has to be run separately.
Still, it's better than reinventing it for every package that needs it.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Brett McCormick wrote:

Can we have all the constants put in pg_type? In the implementation
of my perl PL language, some types I care about aren't defined so I
must define them myself, which seems dangerous (should they ever
change)

On Fri, 27 February 1998, at 12:15:21, Vadim B. Mikheev wrote:

I like second way (and so - we should copy pg_type to ~pgsql/include or
something like this) but it would be nice if you support more
general 1st way too.

We should do this.

Is there anything to prevent someone from deleting that function and
then recreating it? If that happens, it will then have a different oid.

darrenk

Can we have all the constants put in pg_type? In the implementation
of my perl PL language, some types I care about aren't defined so I
must define them myself, which seems dangerous (should they ever
change)

Please submit a patch to pg_type to add the ones you need. Maybe
generating a separate file via a shell script with the oids would be
nice. Gen_fmgr.sh does this, I think.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)