constants for return value from PQftype?

Started by Adam Haberlachover 24 years ago4 messagesgeneral
Jump to latest
#1Adam Haberlach
adam@newsnipple.com

I'm trying to build the PoPy PostgreSQL/Python interface so that
I can use PostgreSQL with Zope, and I'm having some problems:

First, I had to modify PoPy.h so that it would not include
<postgres.h> and <catalog/pg_type.h>, which don't seem to be
moved into the normal include path by the install. I think
that they've been obsoleted and postgres.h has been essentially
replaced with <libpq-fe.h>. In any case, it seems that I got
to this point:

gcc -fPIC -Wstrict-prototypes -Wall -O6 -fomit-frame-pointer -I/usr/local/include/python2.2 -I/usr/local/lib/python2.2/config -DHAVE_CONFIG_H=1 -I/usr/local/pgsql/include -Wall -DVERSION=\"3.0-beta1\" -c ././PoPy.c -o ./PoPy.o
././PoPy.c: In function `PoPy_converter':
././PoPy.c:77: `BOOLOID' undeclared (first use in this function)
././PoPy.c:77: (Each undeclared identifier is reported only once
././PoPy.c:77: for each function it appears in.)
././PoPy.c:83: `INT2OID' undeclared (first use in this function)
././PoPy.c:84: `INT4OID' undeclared (first use in this function)
././PoPy.c:89: `DATEOID' undeclared (first use in this function)
././PoPy.c:90: `TIMEOID' undeclared (first use in this function)
././PoPy.c:91: `TIMESTAMPOID' undeclared (first use in this function)
././PoPy.c:95: `PG_BINARY' undeclared (first use in this function)
././PoPy.c:110: `FLOAT4OID' undeclared (first use in this function)
././PoPy.c:111: `FLOAT8OID' undeclared (first use in this function)
././PoPy.c: At top level:

/***

Here's the code:

***/

ftype = PQftype(result, field);

if(PQgetisnull(result, tuple, field)) {
Py_INCREF(Py_None);
return Py_None;
}

ftype = (ftype>1000 && ftype < 1028?PG_ARRAY:ftype);
switch(ftype) {
case PG_ARRAY_BOOL:
res = PoPy_array_handler(PQgetvalue(result,tuple,field),0);
break;
case PG_ARRAY:

/*****/

I looked through the headers and the documentation. the PG_xxx constants
don't seem to be in the the user include files. I can't seem to find PQftype in
the documentation, or any hint as to what it should be returning. Shouldn't
these constants, or something like them be somewhere in the include files?

--
Adam Haberlach | Who buys an eight-processor machine and then
adam@newsnipple.com | watches 30 movies on it all at the same time?
http://newsnipple.com | Beats me. They told us they could sell it, so
| we made it. -- George Hoffman, Be Engineer

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Adam Haberlach (#1)
Re: constants for return value from PQftype?

Adam Haberlach <adam@newsnipple.com> writes:

First, I had to modify PoPy.h so that it would not include
<postgres.h> and <catalog/pg_type.h>, which don't seem to be
moved into the normal include path by the install.

See "make install-all-headers". You definitely need pg_type.h
for those constants.

This line looks pretty darn fragile:

ftype = (ftype>1000 && ftype < 1028?PG_ARRAY:ftype);

A hardwired test on type OID range might or might not be wrong today,
but it will assuredly be wrong in future.

regards, tom lane

#3Thomas Lockhart
lockhart@fourpalms.org
In reply to: Adam Haberlach (#1)
Re: constants for return value from PQftype?

I'm trying to build the PoPy PostgreSQL/Python interface so that
I can use PostgreSQL with Zope, and I'm having some problems:

...

././PoPy.c: In function `PoPy_converter':
././PoPy.c:77: `BOOLOID' undeclared (first use in this function)

...

I looked through the headers and the documentation. the PG_xxx constants
don't seem to be in the the user include files. I can't seem to find PQftype in
the documentation, or any hint as to what it should be returning. Shouldn't
these constants, or something like them be somewhere in the include files?

These values are not *guaranteed* to be constants across PostgreSQL
releases (though in fact they tend to stay the same). It is possible to
query the database to find them on connection startup (then populate a
Python dictionary with them for lookup?), or you can hardcode them in as
your current code does. As you noted the definitions are not considered
part of client-side code so were removed from the include files.

Are you building PostgreSQL from sources? If so, the definitions are
available in the backend catalog header files...

- Thomas

#4Adam Haberlach
adam@newsnipple.com
In reply to: Thomas Lockhart (#3)
Re: constants for return value from PQftype?

On Tue, Jan 08, 2002 at 02:47:16PM +0000, Thomas Lockhart wrote:

I'm trying to build the PoPy PostgreSQL/Python interface so that
I can use PostgreSQL with Zope, and I'm having some problems:

...

././PoPy.c: In function `PoPy_converter':
././PoPy.c:77: `BOOLOID' undeclared (first use in this function)

...

I looked through the headers and the documentation. the PG_xxx constants
don't seem to be in the the user include files. I can't seem to find PQftype in
the documentation, or any hint as to what it should be returning. Shouldn't
these constants, or something like them be somewhere in the include files?

These values are not *guaranteed* to be constants across PostgreSQL
releases (though in fact they tend to stay the same). It is possible to
query the database to find them on connection startup (then populate a
Python dictionary with them for lookup?), or you can hardcode them in as
your current code does. As you noted the definitions are not considered
part of client-side code so were removed from the include files.

Yeah, I understand the bit about them not being constant from release
to release. I was just wondering if the only way to actually use PQftype was
to query the database. I know that the python api in the contrib dictionary
does this. Can we get a note in the documentation regarding the PQftype that
it returns an Oid that corresponds to some field in some table somewhere in
the system catalog, and that it doesn't necessarily return a commonly
defined constant?

I'll use the 'make install-all-headers' that was mentioned.

Are you building PostgreSQL from sources? If so, the definitions are
available in the backend catalog header files...

I knew this and did some hacking to try and get that to work, but the
going was hard enough that I figured it was officially discouraged, and
hoped there was a better way.

--
Adam Haberlach | Who buys an eight-processor machine and then
adam@newsnipple.com | watches 30 movies on it all at the same time?
http://newsnipple.com | Beats me. They told us they could sell it, so
| we made it. -- George Hoffman, Be Engineer