Thread: constants for return value from PQftype?

constants for return value from PQftype?

From
Adam Haberlach
Date:
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

Re: constants for return value from PQftype?

From
Tom Lane
Date:
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

Re: constants for return value from PQftype?

From
Thomas Lockhart
Date:
> 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

Re: constants for return value from PQftype?

From
Adam Haberlach
Date:
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