Обсуждение: 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.
--
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.
> > 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: > 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
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.
> > > 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)