pypgsql-users — Discussion list for the pyPgSQL user community.

[Pypgsql-users] Re: PgBoolean

[Gerhard <ger...@op...>]

You wrote:
> Can anyone tell me how to programatically check the value of a PgBoolean
> object? I am doing the following:
> 
> #####
> from pyPgSQL import PgSQL
> from pyPgSQL import libpq
> 
> db = PgSQL.connect("localhost::testdb")
> cursor = db.cursor()
> cursor.callproc("sp_TestBoolean", 1, 1)
> retval = cursor.fetchone()
> #####
> 
> When I print the value of retval, I get this:
> [<PgBoolean instance at 0x401c8900: Value: False>]
> 
> I would like to be able to do something like this:
> 
> if retval == true:
>    # do something
> else:
>    # do something else

It's not wise to test for truth values using == true. In Python, you test
wether something is nonzero, or zero.

These are examples of objects that are nonzero:

1, 2, 3, 4, 5, "foobar", [3,4,5], (3,4)

You can see this when you use them in an if-statement:

    >>> if "foobar": print "true"
    ...
    true

These are examples of objects whose truth value is "false":

0, 0.0, "", [], ()

Proof:

    >>> if not 0.0: print "false"
    ...
    false


Now, back to pyPgSQL :-) You simply test for the truth value of PgBooleans
using the if-statement:

    if retval:
       # do something
    else:
       # do something else


As far as "== true" is concerned, this does not exist in Python. *But*
there is are "True" and "False" constants in Python 2.2.2 (these are really
ints in 2.2.2). In Python 2.3 (still in development), we have a real
boolean type.

But please don't do things like:

    if foo == True:
        # ... 

just because that's possible with 2.2.2 and later. Such code hurts my eyes
;-) It's also more verbose than it needs to be. And error-prone, because it
requires that the class or type of foo support comparison to "True".
Checking for the nonzero-ness is much more rubost, and works with all
objects, as you've seen above (ints, longs, floats, strings, lists, etc.).

HTH,
-- 
Gerhard Häring
OPUS GmbH München
Tel.: +49 89 - 889 49 7 - 32
http://www.opus-gmbh.net/

[Pypgsql-users] PgBoolean

[<vze...@ve...>]

Can anyone tell me how to programatically check the value of a PgBoolean object? I am doing the following:

#####
from pyPgSQL import PgSQL
from pyPgSQL import libpq

db = PgSQL.connect("localhost::testdb")
cursor = db.cursor()
cursor.callproc("sp_TestBoolean", 1, 1)
retval = cursor.fetchone()
#####

When I print the value of retval, I get this:
[<PgBoolean instance at 0x401c8900: Value: False>]

I would like to be able to do something like this:

if retval == true:
   # do something
else:
   # do something else

Thanks in advance for your help.

Re: [Pypgsql-users] Re: Escaped apastrophes

[Mike B. <mi...@da...>]

Actually, this ended up being a mistake on my part.  I was just looking at
the returned values in the python interpreter, rather than actually comparing
or printing them.  Thanks for your help :)

On Wed, Nov 13, 2002 at 12:38:06PM +0000, Gerhard H?ring wrote:
> In article <200...@da...>, Mike Barrett wrote:
> > Howdy, so here's my problem:  I've got a database with a bunch
> > of info in it.  One of the fields is a 'text' field.  Whenever
> > I extract data from this field it seems to work out fine,
> > however, this isn't the case whenever there are both
> > apastrophies and double-quotes in the text.  If both appear
> > inside the field, then all of the apastrophies are escaped with
> > a single backslash.
> 
> Can't reproduce that here (pyPgSQL 2.2):
> 
> *Schema:*
> 
> gerhard=# \d test
>        Table "test"
>  Column | Type | Modifiers
> --------+------+-----------
>  a      | text |
> 
> 
> *Code:*
> 
> from pyPgSQL import PgSQL
> 
> con = PgSQL.connect(host="localhost", database="gerhard", user="gerhard")
> cursor = con.cursor()
> 
> x = """Hello, "pyPgSQL" user! What's up?"""
> cursor.execute("insert into test(a) values (%s)", (x,))
> cursor.execute("select a from test where oid=%s", (cursor.oidValue,))
> row = cursor.fetchone()
> assert(row.a == x)
> 
> con.close()
> 
> 
> Can you provide a test case that demonstrates the problem?
> 
> > Any idea why it's doing this?  Any idea how I can change this
> > behavior?  Maybe a PgUnQuoteString-like method or something?
> 
> Nah. This should work transparently. No need to use the low-level
> methods once you're using PgSQL.
> -- 
> Gerhard H?ring
> OPUS GmbH M?nchen
> Tel.: +49 89 - 889 49 7 - 32
> http://www.opus-gmbh.net/
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Are you worried about 
> your web server security? Click here for a FREE Thawte 
> Apache SSL Guide and answer your Apache SSL security 
> needs: http://www.gothawte.com/rd523.html
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users

-- 
     ________________________________________________________________________
                Mike Barrett | "I used to read, now I go to raves."
             mi...@da... | -- Random MUNI Rider, speaking
              www.daboyz.org |    to my friend Allison.
     ------------------------+-----------------------------------------------

[Pypgsql-users] Re: Escaped apastrophes

[Gerhard <ger...@op...>]

In article <200...@da...>, Mike Barrett wrote:
> Howdy, so here's my problem:  I've got a database with a bunch
> of info in it.  One of the fields is a 'text' field.  Whenever
> I extract data from this field it seems to work out fine,
> however, this isn't the case whenever there are both
> apastrophies and double-quotes in the text.  If both appear
> inside the field, then all of the apastrophies are escaped with
> a single backslash.

Can't reproduce that here (pyPgSQL 2.2):

*Schema:*

gerhard=# \d test
       Table "test"
 Column | Type | Modifiers
--------+------+-----------
 a      | text |


*Code:*

from pyPgSQL import PgSQL

con = PgSQL.connect(host="localhost", database="gerhard", user="gerhard")
cursor = con.cursor()

x = """Hello, "pyPgSQL" user! What's up?"""
cursor.execute("insert into test(a) values (%s)", (x,))
cursor.execute("select a from test where oid=%s", (cursor.oidValue,))
row = cursor.fetchone()
assert(row.a == x)

con.close()


Can you provide a test case that demonstrates the problem?

> Any idea why it's doing this?  Any idea how I can change this
> behavior?  Maybe a PgUnQuoteString-like method or something?

Nah. This should work transparently. No need to use the low-level
methods once you're using PgSQL.
-- 
Gerhard Häring
OPUS GmbH München
Tel.: +49 89 - 889 49 7 - 32
http://www.opus-gmbh.net/

[Pypgsql-users] Escaped apastrophes

[Mike B. <mi...@da...>]

    Howdy, so here's my problem:  I've got a database with a bunch of info in
    it.  One of the fields is a 'text' field.  Whenever I extract data from
    this field it seems to work out fine, however, this isn't the case whenever
    there are both apastrophies and double-quotes in the text.  If both appear
    inside the field, then all of the apastrophies are escaped with a single
    backslash.


    Any idea why it's doing this?  Any idea how I can change this behavior?
    Maybe a PgUnQuoteString-like method or something?

    Thanks in advance for any help you can offer.
-- 
     ________________________________________________________________________
                Mike Barrett | "I used to read, now I go to raves."
             mi...@da... | -- Random MUNI Rider, speaking
              www.daboyz.org |    to my friend Allison.
     ------------------------+-----------------------------------------------

Re: [Pypgsql-users] Automatic rollback on error, duplicate key?

[<py...@ru...>]

On Tue, 12 Nov 2002, Billy G. Allie wrote:

> > I'd might as well also ask how to detect different error codes. The
> > inserts into table 2 may fail for other reasons, and in those cases I
> > should do a rollback. I only want to continue if the error is trying
> > to insert a duplicate key. How am I supposed to do that, perform a
> > regex on the error message string? Yuck. Are there error codes in the
> > cursor or connection to look at?
>
> You could do a search on table 2 for the record you are about to insert to see if it exists.  You can then add it if it wasn't found.  That way you avoid the automatic rollback cause by the duplicate key error.

Yep, that's my workaround. I just wanted to explore the issue a bit to
see why I needed to do this. I thought it was something the driver was
doing.

> Alternatively, is the problem with duplicate int8 values in table 2.  Can you use a serial field to assign the values when they are inserted?  This will guarantee uniqueness.  Later versions of PostgreSQL allow for 8 byte serial fields.

No, the int8 values come from somewhere else. This is really a case of
coming across duplicate data that I only need entered into my table
once. And for these situations I've always just done the insert and
trapped the error, so I was just surprised by it not working with
postgres/pypgsql.

I'm all set, thanks everyone!

-Bob

Re: [Pypgsql-users] Automatic rollback on error, duplicate key?

[<py...@ru...>]

On Tue, 12 Nov 2002, Bob Kimble wrote:

> Well, I think that PostgreSQL is behaving exactly as expected by an RDBMS
> performing a transaction.

Uh, I don't think so. The database should never rollback a transaction
unless I tell it to. It's responsibility is to tell me of the
error. What happens after that is up to me. Oracle does this, and I'm
pretty sure DB2 and Sybase do as well.

> Perhaps you could use a rule to achieve what you want. You could create a
> clone of table 2 augmented with a rule that checks to see if the row you just
> inserted into the clone exists already in table 2. If so, it just drops the

Ah, I'll just do a SELECT to see if the row already exists, and if it
does, skip the insert. It's easier. It's just that, I shouldn't have
to. . .

Cheers,

Bob

Re: [Pypgsql-users] Automatic rollback on error, duplicate key?

[Gerhard <ger...@gm...>]

* Bob Kimble <bo...@ip...> [2002-11-12 00:21 -0500]:
> Perhaps you could use a rule to achieve what you want. You could create a 
> clone of table 2 augmented with a rule that checks to see if the row you just 
> inserted into the clone exists already in table 2. [...]

Well, no need for a separate table:

CREATE RULE RUL_MYTABLE_INS AS 
    ON INSERT TO MYTABLE
        WHERE NEW.MYUNIQUECOLUMN IN (
            SELECT MYUNIQUECOLUMN FROM MYTABLE)
DO INSTEAD NOTHING;

-- Gerhard

Re: [Pypgsql-users] Automatic rollback on error, duplicate key?

[Billy G. A. <bg...@mu...>]

py...@ru... wrote:
> [...]
> Can someone point me in the right direction here? I basically want to
> do:
> 
>             open a new transaction
> 
>             insert row into table 1
> 
>             insert multiple rows into table 2
>                these inserts may be duplicates
> 
>             insert multiple rows into table 3, each of which is tied
>             back to table 1 by an ID.
> 
>             commit the transaction
> 
> For all statements except the inserts into table 2, if I get an error
> I would like to rollback the transaction.
> 
> I'd might as well also ask how to detect different error codes. The
> inserts into table 2 may fail for other reasons, and in those cases I
> should do a rollback. I only want to continue if the error is trying
> to insert a duplicate key. How am I supposed to do that, perform a
> regex on the error message string? Yuck. Are there error codes in the
> cursor or connection to look at?

You could do a search on table 2 for the record you are about to insert to see if it exists.  You can then add it if it wasn't found.  That way you avoid the automatic rollback cause by the duplicate key error.

Alternatively, is the problem with duplicate int8 values in table 2.  Can you use a serial field to assign the values when they are inserted?  This will guarantee uniqueness.  Later versions of PostgreSQL allow for 8 byte serial fields.
-- 
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

Re: [Pypgsql-users] Automatic rollback on error, duplicate key?

[Bob K. <bo...@ip...>]

On Monday 11 November 2002 08:04 pm, py...@ru... wrote:
<snip>
> Can someone point me in the right direction here? I basically want to
> do:
>
>             open a new transaction
>
>             insert row into table 1
>
>             insert multiple rows into table 2
>                these inserts may be duplicates
>
>             insert multiple rows into table 3, each of which is tied
>             back to table 1 by an ID.
>
>             commit the transaction
>
> For all statements except the inserts into table 2, if I get an error
> I would like to rollback the transaction.
<snip>

Well, I think that PostgreSQL is behaving exactly as expected by an RDBMS=
=20
performing a transaction. I use a similar technique in a Java app, but on=
ly=20
for the part involving the inserts into row 2. However, the key differenc=
e is=20
that I'm able to make each insert a separate transaction.

Perhaps you could use a rule to achieve what you want. You could create a=
=20
clone of table 2 augmented with a rule that checks to see if the row you =
just=20
inserted into the clone exists already in table 2. If so, it just drops t=
he=20
new row. If not, it inserts the row into table 2. Basically, the clone ta=
ble=20
just consumes each row inserted into it. You replace the "insert multiple=
=20
rows into table 2" part with "insert multiple rows into table 2's clone."=
 I'm=20
not sure this approach will work, but it seems to be worth a try.

Regards,

=2E... Bob

Re: [Pypgsql-users] Automatic rollback on error, duplicate key?

[Billy G. A. <bg...@mu...>]

py...@ru... wrote:
> 
> Gerhard, thanks for responding so quickly!
> 
> > No, that is indeed what's currently going on. I agree it's odd and I
> > think it should be changed. The only question is: how exactly should the
> > behaviour be? Hmm. Maybe I should look how psycopg implement it.
> 
> I just received a note from a friend of mine:
> 
>   > You're not going to like the answer you get -- it's not a function of
>   > the Python driver, it's the database itself. Postgres treats a duplicate
>   > key in a unique index as an error so it rolls back the entire transaction
> 
>   > Very lame, I know -- I ran into this when I was setting up
>   > . . .
>   > . . .
>   > This is documented as a possible future enhancement:
>   >
>   >    http://www.postgresql.org/idocs/index.php?wal.html
> 
> Oops. I've done this a lot before, but I guess it was always with
> Oracle, and not Postgres. It sounds like there's nothing pypgsql can
> do to avoid it?
> 
> -Bob
This is indeed the case.  In fact, special care was needed in PgSQL in order to try to get back to a sane state when PostgreSQL aborted the transaction.  Here is the relevant code snippet:

        except OperationalError, msg:
            # Uh-oh.  A fatal error occurred.  This means the current trans-
            # action has been aborted.  Try to recover to a sane state.
            if self.conn.inTransaction:
                _n = len(self.conn.notices)
                self.conn.conn.query('ROLLBACK WORK')
                if len(self.conn.notices) != _n:
                    raise Warning, self.conn.notices.pop()
                self.conn.__dict__["inTransaction"] = 0
                self.conn._Connection__closeCursors()
            raise OperationalError, msg

-- 
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

Re: [Pypgsql-users] Automatic rollback on error, duplicate key?

[<py...@ru...>]

Gerhard, thanks for responding so quickly!

> No, that is indeed what's currently going on. I agree it's odd and I
> think it should be changed. The only question is: how exactly should the
> behaviour be? Hmm. Maybe I should look how psycopg implement it.

I just received a note from a friend of mine:

  > You're not going to like the answer you get -- it's not a function of
  > the Python driver, it's the database itself. Postgres treats a duplicate
  > key in a unique index as an error so it rolls back the entire transaction

  > Very lame, I know -- I ran into this when I was setting up
  > . . .
  > . . .
  > This is documented as a possible future enhancement:
  >
  >    http://www.postgresql.org/idocs/index.php?wal.html

Oops. I've done this a lot before, but I guess it was always with
Oracle, and not Postgres. It sounds like there's nothing pypgsql can
do to avoid it?

-Bob

Re: [Pypgsql-users] Automatic rollback on error, duplicate key?

[Gerhard <ger...@gm...>]

* py...@ru... <py...@ru...> [2002-11-11 17:04 -0800]:
> [...] I've just started a project using python and pypgsql and I've
> run into something I consider odd.
> 
> I have a table defined as:
> 
> create table items (
>   gid        int8 UNIQUE,
>   name       varchar(256),
>   descr      varchar(1024)
> );
> 
> Over time I'll be inserting rows into the items table, and I may have
> duplicates.  I expect the insert to fail, and I don't care, I just
> want to continue inserting other items, and more importantly, I want
> previous inserts to this table and other tables to not disappear.
> 
> When I code this in a way that I thought should work, it appears that
> the pypgsql module is doing an automatic rollback when I insert a
> duplicate:
> 
>             try:
>                 cur.execute(sqlStmt)
>             except PgSQL.Error, msg:
>                 print "Insert from pg_database failed\n%s" % msg
>                 print sqlStmt
> 
> It seems to me that, since I am trapping the error, it should be up to
> me to decide if a rollback() should be performed. Why is the module
> deciding for me? Or have I misunderstood what is going on?

No, that is indeed what's currently going on. I agree it's odd and I
think it should be changed. The only question is: how exactly should the
behaviour be? Hmm. Maybe I should look how psycopg implement it.

> I took a look at the DB API 2.0 spec at
> http://www.python.org/peps/pep-0249.html but I can't see where this
> behavior is defined (or any detailed error handling behavior,
> actually).
> 
> Can someone point me in the right direction here? I basically want to
> do:
> 
>             open a new transaction
> 
>             insert row into table 1
> 
>             insert multiple rows into table 2
>                these inserts may be duplicates
> 
>             insert multiple rows into table 3, each of which is tied
>             back to table 1 by an ID.
> 
>             commit the transaction
> 
> For all statements except the inserts into table 2, if I get an error
> I would like to rollback the transaction.

ISTM that to achieve the above goal using pyPgSQL, you currently will
have to set the the autocommit property of the connection to 1 and issue
the BEGIN/ROLLBACK/COMMIT statements yourself using cursor.execute,
catching exceptions appropriately.

> I'd might as well also ask how to detect different error codes. The
> inserts into table 2 may fail for other reasons, and in those cases I
> should do a rollback. I only want to continue if the error is trying
> to insert a duplicate key. How am I supposed to do that, perform a
> regex on the error message string?

Yes.

> Yuck.

Indeed.

> Are there error codes in the cursor or connection to look at?

Nope. PostgreSQL doesn't have any error codes. With a little chance,
this will be worked on for version 7.4, if I read pgsql-hackers
correctly.

-- Gerhard

[Pypgsql-users] Automatic rollback on error, duplicate key?

[<py...@ru...>]

I'm new to both python and the pypgsql module, but have been using
Oracle since 1996 and Postgres for the last 2 years. I've used a
number of interfaces to both including low-level C interfaces. I've
just started a project using python and pypgsql and I've run into
something I consider odd.

I have a table defined as:

create table items (
  gid        int8 UNIQUE,
  name       varchar(256),
  descr      varchar(1024)
);

Over time I'll be inserting rows into the items table, and I may have
duplicates.  I expect the insert to fail, and I don't care, I just
want to continue inserting other items, and more importantly, I want
previous inserts to this table and other tables to not disappear.

When I code this in a way that I thought should work, it appears that
the pypgsql module is doing an automatic rollback when I insert a
duplicate:

            try:
                cur.execute(sqlStmt)
            except PgSQL.Error, msg:
                print "Insert from pg_database failed\n%s" % msg
                print sqlStmt

It seems to me that, since I am trapping the error, it should be up to
me to decide if a rollback() should be performed. Why is the module
deciding for me? Or have I misunderstood what is going on?

I took a look at the DB API 2.0 spec at
http://www.python.org/peps/pep-0249.html but I can't see where this
behavior is defined (or any detailed error handling behavior,
actually).

Can someone point me in the right direction here? I basically want to
do:

            open a new transaction

            insert row into table 1

            insert multiple rows into table 2
               these inserts may be duplicates

            insert multiple rows into table 3, each of which is tied
            back to table 1 by an ID.

            commit the transaction

For all statements except the inserts into table 2, if I get an error
I would like to rollback the transaction.

I'd might as well also ask how to detect different error codes. The
inserts into table 2 may fail for other reasons, and in those cases I
should do a rollback. I only want to continue if the error is trying
to insert a duplicate key. How am I supposed to do that, perform a
regex on the error message string? Yuck. Are there error codes in the
cursor or connection to look at?

Thanks!

Bob

Re: [Pypgsql-users] Re: [ANN] pyPgSQL 2.3 beta 1 released

[Steven D. A. <st...@ne...>]

On 11/2/02 12:55 AM, "bob ackerman" <rd...@pa...> wrote:

> (i sent this to steve directly -- this corrects mistake by sending to list)
> 
> On Friday, November 1, 2002, at 09:18  PM, Steven D. Arnold wrote:
> 
> I tried compiling pyPgSQL 2.3 beta 1 with the result below.  I did not
> modify the setup.py; there was nothing obvious to change.
> 
> Macintosh-2.3/pyPgSQL/libpq/libpqmodule.so
> ld: table of contents for archive: /usr/local/pgsql/lib/libpq.a is out of
> date; rerun ranlib(1) (can't load from it)
> error: command 'gcc' failed with exit status 1
> 
> i don't know details, but when this happened to me i did what it said:
> run 'ranlib' then try again. i forget but think ranlib needs to run in
> that directory with that lib as an argument.

Just to let everyone know -- this worked for me too.

steve
-- 

Re: [Pypgsql-users] Re: [ANN] pyPgSQL 2.3 beta 1 released

[bob a. <rd...@pa...>]

(i sent this to steve directly -- this corrects mistake by sending to list)

On Friday, November 1, 2002, at 09:18  PM, Steven D. Arnold wrote:

I tried compiling pyPgSQL 2.3 beta 1 with the result below.  I did not
modify the setup.py; there was nothing obvious to change.

Macintosh-2.3/pyPgSQL/libpq/libpqmodule.so
ld: table of contents for archive: /usr/local/pgsql/lib/libpq.a is out of
date; rerun ranlib(1) (can't load from it)
error: command 'gcc' failed with exit status 1

i don't know details, but when this happened to me i did what it said:
run 'ranlib' then try again. i forget but think ranlib needs to run in 
that directory with that lib as an argument.

Re: [Pypgsql-users] Re: [ANN] pyPgSQL 2.3 beta 1 released

[Steven D. A. <st...@ne...>]

On 11/2/02 12:18 AM, "Steven D. Arnold" <st...@ne...> wrote:

> I tried compiling pyPgSQL 2.3 beta 1 with the result below.  I did not
> modify the setup.py; there was nothing obvious to change.

Uh...no doubt it would be good to add that this was on Mac OS X 10.2, dual
processor 1 GHz.  Sorry.

steve
-- 

[Pypgsql-users] Re: [ANN] pyPgSQL 2.3 beta 1 released

[Steven D. A. <st...@ne...>]

I tried compiling pyPgSQL 2.3 beta 1 with the result below.  I did not
modify the setup.py; there was nothing obvious to change.

[thoth@paranoia:~/Source/pypgsql] > sudo python setup.py install
Password:
running install
running build
running build_py
creating build
creating build/lib.darwin-6.1-Power Macintosh-2.3
creating build/lib.darwin-6.1-Power Macintosh-2.3/pyPgSQL
copying pyPgSQL/__init__.py -> build/lib.darwin-6.1-Power
Macintosh-2.3/pyPgSQL
copying pyPgSQL/PgSQL.py -> build/lib.darwin-6.1-Power Macintosh-2.3/pyPgSQL
creating build/lib.darwin-6.1-Power Macintosh-2.3/pyPgSQL/libpq
copying pyPgSQL/libpq/__init__.py -> build/lib.darwin-6.1-Power
Macintosh-2.3/pyPgSQL/libpq
running build_ext
building 'pyPgSQL.libpq.libpqmodule' extension
creating build/temp.darwin-6.1-Power Macintosh-2.3
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
pgconnection.c -o build/temp.darwin-6.1-Power Macintosh-2.3/pgconnection.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
libpqmodule.c -o build/temp.darwin-6.1-Power Macintosh-2.3/libpqmodule.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
pgboolean.c -o build/temp.darwin-6.1-Power Macintosh-2.3/pgboolean.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
port/strtoull.c -o build/temp.darwin-6.1-Power Macintosh-2.3/strtoull.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
pymemstrdup.c -o build/temp.darwin-6.1-Power Macintosh-2.3/pymemstrdup.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
port/strtoll.c -o build/temp.darwin-6.1-Power Macintosh-2.3/strtoll.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
pgversion.c -o build/temp.darwin-6.1-Power Macintosh-2.3/pgversion.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
port/strtok.c -o build/temp.darwin-6.1-Power Macintosh-2.3/strtok.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
pgint2object.c -o build/temp.darwin-6.1-Power Macintosh-2.3/pgint2object.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
pgint8object.c -o build/temp.darwin-6.1-Power Macintosh-2.3/pgint8object.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
pgnotify.c -o build/temp.darwin-6.1-Power Macintosh-2.3/pgnotify.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
pglargeobject.c -o build/temp.darwin-6.1-Power Macintosh-2.3/pglargeobject.o
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/pgsql/include -I/usr/local/include/python2.3 -c
pgresult.c -o build/temp.darwin-6.1-Power Macintosh-2.3/pgresult.o
gcc -bundle -bundle_loader /usr/local/bin/python build/temp.darwin-6.1-Power
Macintosh-2.3/libpqmodule.o build/temp.darwin-6.1-Power
Macintosh-2.3/pgboolean.o build/temp.darwin-6.1-Power
Macintosh-2.3/pgint2object.o build/temp.darwin-6.1-Power
Macintosh-2.3/pgint8object.o build/temp.darwin-6.1-Power
Macintosh-2.3/pgversion.o build/temp.darwin-6.1-Power
Macintosh-2.3/pglargeobject.o build/temp.darwin-6.1-Power
Macintosh-2.3/pgnotify.o build/temp.darwin-6.1-Power
Macintosh-2.3/pgconnection.o build/temp.darwin-6.1-Power
Macintosh-2.3/pgresult.o build/temp.darwin-6.1-Power
Macintosh-2.3/pymemstrdup.o build/temp.darwin-6.1-Power
Macintosh-2.3/strtoll.o build/temp.darwin-6.1-Power Macintosh-2.3/strtoull.o
build/temp.darwin-6.1-Power Macintosh-2.3/strtok.o -L/usr/local/pgsql/lib
-lpq -lssl -lcrypto -o build/lib.darwin-6.1-Power
Macintosh-2.3/pyPgSQL/libpq/libpqmodule.so
ld: table of contents for archive: /usr/local/pgsql/lib/libpq.a is out of
date; rerun ranlib(1) (can't load from it)
error: command 'gcc' failed with exit status 1

-- 

[Pypgsql-users] [ANN] pyPgSQL 2.3 beta 1 released

[Gerhard <ger...@gm...>]

Announce: pyPgSQL - Version 2.3 beta 1 is released.
===========================================================================

pyPgSQL v2.3 beta 1 has been released.

It is available at http://pypgsql.sourceforge.net.

pyPgSQL is a package of two (2) modules that provide a Python DB-API 2.0
compliant interface to PostgreSQL databases. The first module, libpq, is
written in C and exports the PostgreSQL C API to Python.  The second module,
PgSQL, provides the DB-API 2.0 compliant interface and support for various
PostgreSQL data types, such as INT8, NUMERIC, MONEY, BOOL, ARRAYS, etc. This
module is written in Python and works with PostgreSQL 7.0 or later and Python
2.0 or later.

It was tested with PostgreSQL 7.0.3, 7.1.3, 7.2.2, 7.3 beta 2, Python 2.0.1,
2.1.3 and 2.2.2.

Note: It is highly recommended that you use PostgreSQL 7.1 or later and Python
2.1 or later.  If you want to use PostgreSQL Large Objects under Python 2.2.x,
you *must* use Python 2.2.2, because of a bug in earlier 2.2 versions.

Project homepages:
pyPgSQL:        http://pypgsql.sourceforge.net/
PostgreSQL:     http://www.postgresql.org/
Python:         http://www.python.org/

This is the first time we release a beta of pyPgSQL.  While there didn't change
much under the hood, the build process was completely rewritten, so pyPgSQL
should now build out of the box on most popular platforms.  For you, this means
that a "python setup.py build" will now hopefully just work. And for us, this
means we'll have to answer less boring support questions :-)

    These platforms were tested and will build out of the box (of course, more
    testing won't hurt): UnixWare 7/OpenUNIX 8, Windows native, Cgwin, FreeBSD
    4.7, Redhat Linux 7.3, SuSE Linux 7.3, Debian Linux 3.0.

    The build process is also designed to work with these platforms, but they
    could not be tested in real life (please do so, if you can!): Mandrake
    Linux, NetBSD, OpenBSD, MacOS X.

    If your platform isn't supported out of the box, you can edit a
    setup.config file to configure the build process.  Patches for supporting
    additional platforms are more than welcome. Look into setup.py for how to
    do it.

The other big change is that Gerhard finally gave up on getting more feedback
on his Unicode patch and merged it into the pyPgSQL 2.x line.  Hey, if it did
work for Linux 2.4, it can work for us, too <0.7 wink>.

Using Unicode works like this:

    from pyPgSQL import PgSQL
    con = PgSQL.connect(client_encoding=("utf-8", "ignore"), unicode_results=1)

    # where client_encoding are the parameters you normally give to the encode
    # method of a Unicode string. unicode_results=1 means pyPgSQL will return
    # VARCHAR/CHAR/TEXT fields as Unicode strings instead of byte strings.

    # As I refuse to do any magic, you'll also have to set the client encoding
    # for the database manually:
    cursor = con.cursor()
    cursor.execute("SET CLIENT_ENCODING TO UNICODE")

    # There are other ways to set the client encoding, including setting a
    # special environment variable (see PostgreSQL manual), but I recommend
    # doing it in code. 

---------------------------------------------------------------------------
ChangeLog:
===========================================================================

Changes since pyPgSQL Version 2.2
=================================

The following source code files were added to Version 2.3 beta 1 of pyPgSQL:

    setup.config	- Part of the changed distutils-based build process.
			  If you want to customize the build process (change
			  include and library directories, for example, you
			  only need to edit this file; setup.py should not be
			  edited directly any longer)

    unicode_tests.py	- Test suite for the new Unicode support. Merged from
			  the Unicode patch.

Changes to setup.py
-------------------
* This file was rewritten entirely so that pyPgSQL now builds out of the box
  on Windows, Cygwin, Debian Linux, Redhat Linux, SuSE Linux, FreeBSD,
  UnixWare 7 and OpenUNIX 8. These are the platforms the new build process has
  been tested on. Untested support is available for Mandrake Linux, NetBSD,
  OpenBSD and MacOS X.

Changes to README
-----------------
* Updates for 2.3b1.
* Converted the whole document into reStructuredText, so we
  can easily built a HTML version using docutils (http://docutils.sf.net/).

Changes to README.win32
-----------------------
* Remove out of date warning about PostgreSQL on win32
* Reflected change from windows/ to ports/

Changes to PgSQL.py
-------------------
* Merged the Unicode patch. pyPgSQL now has full Unicode support.
* Added support for the INTERVAL type.
* mxDateTime 1.x is no longer supported. Require mxDateTime 2.x and give
  useful error message if import fails.
* Cosmetic changes: use cmp builtin where appropriate.
* Fixed typo where PgTypes.__str__ was spelled incorrectly; compare to None
  using "is" operator.
* Take into account that libpq.PgInt8Type might not be
  available.
* Convert ROWID to PgInt8 instead of PgInt4 (the original behaviour led to 
  overflow errors.)
* Always set the displaysize field of cursor.description to -1.
  PostgreSQL 7.3 doesn't provide this information any more and it's pretty
  useless nowadays that we've mostly left line printers beyond us.

Changes to pyPgSQL/__init__.py
------------------------------
* Register libpq.PgInt8 with copy_reg only if available.

Changes to pglargeobject.c
--------------------------
* Made the 'closed' attribute of PgLargeObject an int instead of a
  long.
	
Changes to libpqmodule.c:
-------------------------
* Fixed the format string of ParseTuple in libPQbool_FromInt.
  This closes a bug that appeared on Linux/Alpha (#625121).
	
Changes to PgSQLTestcases:
--------------------------
* Don't check for the obsolete displaysize field in
  cursor.description. Also don't check the backend encoding.

Multiple files
--------------
The windows/ directory has been moved to a port/ directory. Now we *always*
use our own version of various string versions instead of special casing for a
dozen different Windows and Unix platforms.

In order to get the C version of PgInt8Type, it is now required that the
constants LLONG_MAX, LLONG_MIN, ULLONG_MAX and ULLONG_MIN are defined when
including limits.h and that including Python.h defines HAVE_LONG_LONG.
Otherwise, a Python class is used instead.

[Pypgsql-users] Re: Difficulty using pypgsql rpm

[Stanley A. K. <sk...@cp...>]

I got it working.  Thanks for the advice.

I prepared a patch for setup.py to change the include and library locations
to the third alternative and revised the spec file to apply it.  Somehow,
it still built an rpm that installed in /usr/lib/python2.2/site-packages
(even though I built the rpm with python 2.1 and there isn't anything else
in the python 2.2 directory) but I symlinked it over to
/usr/lib/python2.1/site-packages, where it needed to be.

I also need to find better documentation on preparing patches, because it
had to ask me to name the file that was to receive the patch.

Again, thanks.


Stan Klein


At 01:15 PM 10/21/2002 -0600, Sean Reifschneider wrote:
>On Mon, Oct 21, 2002 at 10:55:26AM +0000, Stanley A. Klein wrote:
>>I'm running Python 2.1, which if it wasn't provided on the Red Hat 7.2 CD's
>>(in addition to the Python 1.5.2 that runs the Red Hat config system) I had
>>downloaded from python.org.
>
>The RPMs you get from python.org should install as the name "python2".
>You're probably running a Python that you got elsewhere.
>
>>I had installed the pypgsql 2.1 and 2.2 rpms downloaded from ftp.tummy.com.
>> I tried both.  They each created a python2.2 site packages directory and I
>>symlinked pypgsql from there to the python2.1 site packages directory.
>
>Yeah, don't do that.  Either install Python 2.2, or re-build the pyPgSQL
>with 2.1...
>
>>My suspicion is that the options in setup.py somehow cause the pypgsql 2.1
>>and 2.2 installed under the rpms as supplied on the ftp site to look in the
>>wrong places for some shared objects they need.
>
>Perhaps.  You *DO* have the postgres libraries installed, right?  I
>believe the package name is "postgresql-libs"?
>
>>Since the SRPM keeps the source files other than the rpm spec packaged up
>>in a tar.gz file that the rpm build uses, I'm not sure how to fix the
>>setup.py inside the tar.gz package to select the proper options for Red
>>Hat.  Alternatively, could I symlink from where Red Hat puts any library or
>
>You have to provide a patch to the source, and specify it via the
>"patch0:" and "%patch0" lines in the .spec file.  The tar file in the
>SRPM is always a pristine copy of the source, the build process then
>applies patches to it.
>
>You probably don't need to do this though.
>
>Sean
>-- 
> Reading computer manuals without the hardware is as frustrating as reading
> sex manuals without the software.  -- Arthur C. Clarke
>Sean Reifschneider, Inimitably Superfluous <ja...@tu...>
>tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin
>
>

[Pypgsql-users] Re: Difficulty using pypgsql rpm

[Sean R. <ja...@tu...>]

On Mon, Oct 21, 2002 at 10:55:26AM +0000, Stanley A. Klein wrote:
>I'm running Python 2.1, which if it wasn't provided on the Red Hat 7.2 CD's
>(in addition to the Python 1.5.2 that runs the Red Hat config system) I had
>downloaded from python.org.

The RPMs you get from python.org should install as the name "python2".
You're probably running a Python that you got elsewhere.

>I had installed the pypgsql 2.1 and 2.2 rpms downloaded from ftp.tummy.com.
> I tried both.  They each created a python2.2 site packages directory and I
>symlinked pypgsql from there to the python2.1 site packages directory.

Yeah, don't do that.  Either install Python 2.2, or re-build the pyPgSQL
with 2.1...

>My suspicion is that the options in setup.py somehow cause the pypgsql 2.1
>and 2.2 installed under the rpms as supplied on the ftp site to look in the
>wrong places for some shared objects they need.

Perhaps.  You *DO* have the postgres libraries installed, right?  I
believe the package name is "postgresql-libs"?

>Since the SRPM keeps the source files other than the rpm spec packaged up
>in a tar.gz file that the rpm build uses, I'm not sure how to fix the
>setup.py inside the tar.gz package to select the proper options for Red
>Hat.  Alternatively, could I symlink from where Red Hat puts any library or

You have to provide a patch to the source, and specify it via the
"patch0:" and "%patch0" lines in the .spec file.  The tar file in the
SRPM is always a pristine copy of the source, the build process then
applies patches to it.

You probably don't need to do this though.

Sean
-- 
 Reading computer manuals without the hardware is as frustrating as reading
 sex manuals without the software.  -- Arthur C. Clarke
Sean Reifschneider, Inimitably Superfluous <ja...@tu...>
tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin

[Pypgsql-users] Re: Difficulty using pypgsql rpm

[Stanley A. K. <sk...@cp...>]

Sean -

I think you misinterpreted my configuration.  Perhaps I wasn't clear.

I'm running Python 2.1, which if it wasn't provided on the Red Hat 7.2 CD's
(in addition to the Python 1.5.2 that runs the Red Hat config system) I had
downloaded from python.org.

I had installed the pypgsql 2.1 and 2.2 rpms downloaded from ftp.tummy.com.
 I tried both.  They each created a python2.2 site packages directory and I
symlinked pypgsql from there to the python2.1 site packages directory.

Neither worked when I did the diagnostic I described.  That was the error
traceback I provided.

My suspicion is that the options in setup.py somehow cause the pypgsql 2.1
and 2.2 installed under the rpms as supplied on the ftp site to look in the
wrong places for some shared objects they need.

Since the SRPM keeps the source files other than the rpm spec packaged up
in a tar.gz file that the rpm build uses, I'm not sure how to fix the
setup.py inside the tar.gz package to select the proper options for Red
Hat.  Alternatively, could I symlink from where Red Hat puts any library or
include files that need to be accessed by the files installed by the
pypgsql rpm to where pypgsql looks for them?  What files are involved?

I understand from your response what the python2 in the spec file
represents.  

Thanks in advance for your help on the remaining items.


Stan Klein



At 10:23 AM 10/21/2002 -0600, Sean Reifschneider wrote:
>On Mon, Oct 21, 2002 at 07:05:42AM +0000, Stanley A. Klein wrote:
>>BTW, I got pyPgSQL to appear in python2.1/site-packages by a symbolic link
>>from where it installs under the rpm as provided.
>
>You can't just symlink the files from a 1.5.2 build into the 2.1/2.2
>directories and expect it to work.  You'll need to build a version of
>pypgsql for the 2.1 install native.  The .spec file doesn't include any
>mechanism for doing that, but if while you build the RPM you make sure
>that /usr/bin/python points at the appropriate version, I think it'll do
>the right thing for you.
>
>>Also, the rpm dependencies specify python2.  Python 2.1 does not qualify
>>under the dependency as stated.  You may want to specify something like
>>python >= 2.  Likewise, my python2.1 requires that it be invoked as
>>python2.1, not python2.  Is a symbolic link required there?
>
>Note that "python2" is different than "python version 2".  With Red Hat
>7.3, if you remove the stock python (1.5.2), it will break the GUI
>management tools.  Therefore, I named the Python 2.x packages "python2",
>so that they could be installed next to the existing system.
>
>You may want to try picking up the python 2.2 RPMs from www.python.org
>(which are the "python2" packages) and using that instead of packages
>that install as "python".
>
>Those were the packages I built pyPgSQL with and should work.
>
>Sean
>-- 
> I'm one of the leading experts in the field of Data Mimeing.  Unfortunately,
> I'm not allowed to TELL you anything about it.  -- Sean Reifschneider, 1997
>Sean Reifschneider, Inimitably Superfluous <ja...@tu...>
>tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin
>
>

[Pypgsql-users] Re: Difficulty using pypgsql rpm

[Sean R. <ja...@tu...>]

On Mon, Oct 21, 2002 at 07:05:42AM +0000, Stanley A. Klein wrote:
>BTW, I got pyPgSQL to appear in python2.1/site-packages by a symbolic link
>from where it installs under the rpm as provided.

You can't just symlink the files from a 1.5.2 build into the 2.1/2.2
directories and expect it to work.  You'll need to build a version of
pypgsql for the 2.1 install native.  The .spec file doesn't include any
mechanism for doing that, but if while you build the RPM you make sure
that /usr/bin/python points at the appropriate version, I think it'll do
the right thing for you.

>Also, the rpm dependencies specify python2.  Python 2.1 does not qualify
>under the dependency as stated.  You may want to specify something like
>python >= 2.  Likewise, my python2.1 requires that it be invoked as
>python2.1, not python2.  Is a symbolic link required there?

Note that "python2" is different than "python version 2".  With Red Hat
7.3, if you remove the stock python (1.5.2), it will break the GUI
management tools.  Therefore, I named the Python 2.x packages "python2",
so that they could be installed next to the existing system.

You may want to try picking up the python 2.2 RPMs from www.python.org
(which are the "python2" packages) and using that instead of packages
that install as "python".

Those were the packages I built pyPgSQL with and should work.

Sean
-- 
 I'm one of the leading experts in the field of Data Mimeing.  Unfortunately,
 I'm not allowed to TELL you anything about it.  -- Sean Reifschneider, 1997
Sean Reifschneider, Inimitably Superfluous <ja...@tu...>
tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin

[Pypgsql-users] Difficulty using pypgsql rpm

[Stanley A. K. <sk...@cp...>]

I've been having a problem using pyPgSQL as installed from the rpms on a
Red Hat 7.2 system.  I have been trying to bring up GNU Enterprise 0.4
(www.gnuenterprise.org) for which pyPgSQL is one of the possible supported
database drivers.

When I try to bring up GNUe Designer, I get an error message to the effect
that the database driver isn't there.  I tried going into Python directly
(I'm running Python 2.1) and doing "from pyPgSQL import PgSQL" as suggested
for diagnosis by a member of the GNUe Core Team.  When I do, I get the
following traceback:

Python 2.1.2 (#1, Feb  1 2002, 15:17:37)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/site-packages/pyPgSQL/PgSQL.py", line 330, in ?
    from libpq import *
  File "/usr/lib/python2.1/site-packages/pyPgSQL/libpq/__init__.py", line
23, in ?
    from libpq import *
ImportError: : shared object not open

BTW, I got pyPgSQL to appear in python2.1/site-packages by a symbolic link
from where it installs under the rpm as provided.

I looked at the rpm spec file and the setup.py file in the tarball.  There
are aome alternatives provided for the library and include directories.
The Red Hat installation places its directories consistent with second
alternative (commented out in the distributed setup.py). 

What do I need to do to get pypgsql working on my Red Hat 7.2 system?  Can
you provide me a set of directions?

Also, the rpm dependencies specify python2.  Python 2.1 does not qualify
under the dependency as stated.  You may want to specify something like
python >= 2.  Likewise, my python2.1 requires that it be invoked as
python2.1, not python2.  Is a symbolic link required there?


Stan Klein

Re: [Pypgsql-users] [ANN] Newsgroup gateway of this list

[Gerhard <ger...@gm...>]

* Mark McEahern <mar...@mc...> [2002-10-10 12:03 -0500]:
> [Gerhard Häring]
> > Hi folks. As this mailing list is getting excessive traffic <wink>,
> > there has been a mail-to-news/news-to-mail gateway installed at
> > gmane.org.
> >
> > News server: news.gmane.org
> > Newsgroup:   gmane.comp.python.db.pypgsql.user
> >
> > news.gmane.org carries many gatewayed Python related mailing lists,
> > and tons of other lists, too, like for PostgreSQL, Debian, FreeBSD,
> > Apache, ...
> 
> Gerhard, as an aside, does this mean the group's postings will be searchable
> via http://google.groups.com/?

No, news.gmane.org doesn't share its feed with other newsservers, so
postings never propagates to Google's newsserver.

> That, to me, is a big upside to the fact that the Python list is mirrored to
> comp.lang.python.  If only Python-Dev were too.

Check out http://aspn.activestate.com/ASPN/Mail/ They have searchable
archives for many Python related lists, including python-dev.

I personally have downloaded the mbox archives of the Python SIG groups
I'm interested in and use my MUA to search in them. That doesn't easily
work for mailing lists hosted on Sourceforge, though. You'd have to ask
the list admin (Bill Allie here) to send you an mbox archive, as only
list admins have access to these archives for Sourceforge lists.

Speaking of which, I have a complete archive of this list, too, so if
anybody's interested, just drop me a note.

-- Gerhard