RELEASE: psycopg 1.1.14pre1

Hi *,

sorry for being less responsive lately, the hot weathers here make me
really sleepy.. anyway, I tried to put as much fixes in psycopg 1.1.14
as possible and I'll release early next week if nothing bad arise.
please test this release candidate as much as possible:

  http://initd.org/pub/software/psycopg/psycopg-1.1.14pre1.tar.gz

what changed from 1.1.13? zpsycopgda has got two improvement:

      * it is now possible to specify the backend encoding and let
        psycopgda automatically convert unicode strings (the default is
        UTF-8, go to the properties tab to change it)
      * it is possible to pass an optional "bound variables" parameter
        when directly calling query() on the connection; if you don't
        understand what i am saying you probably don't need it. :)

other fixes include a better interval typecaster and more DBAPI-2.0
compliance (rowcount, arguments to unused functions.)

callproc is still broken (as always), use execute("SELECT proc(...)").

have fun,
federico

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
INIT.D Developer                                           fog@...

RE: bytea problems

Im not sure if the problem you are having is similar to the one I had.  When
I was doing large selects in Solaris I would get weird results.  I ended up
fixing the problem with:

Rebuild Postgres with the "-D_REENTRANT" flag.  Im not sure if that will
help you or not, but it fixed my problem.  Its worth a shot possibly.

>From what I understand, with the -D_REENTRANT flag set it defines errno to
be a function call instead of a global variable.  This supposedly fixes many
problems with solaris libpq threading problems.

For more info:
http://groups.google.com/groups?q=postgres%20solaris%20D_REENTRANT&hl=en&lr=
&ie=UTF-8&sa=N&tab=wg

liam

-----Original Message-----
From: psycopg-bounces@...
[mailto:psycopg-bounces@...] On Behalf Of Richard Moon
Sent: Wednesday, June 30, 2004 1:45 AM
To: psycopg@...
Subject: Re: [Psycopg] bytea problems

I'm already using the psycopg.Binary call as you mentioned - After
digging deeper it may well be a problem with libpq and threads on
solaris.

Regards

RE: bytea problems

Cheers for this - this cracked the problem completely - we have an early
7.4 version of postgres and it looks like this flag is now in the build
file for solaris by default in 7.4.3.

Thanks again

Richard

On Thu, 2004-07-01 at 15:25, Liam Slusser wrote:
> Im not sure if the problem you are having is similar to the one I had.  When
> I was doing large selects in Solaris I would get weird results.  I ended up
> fixing the problem with:
> 
> Rebuild Postgres with the "-D_REENTRANT" flag.  Im not sure if that will
> help you or not, but it fixed my problem.  Its worth a shot possibly.
> 
> >From what I understand, with the -D_REENTRANT flag set it defines errno to
> be a function call instead of a global variable.  This supposedly fixes many
> problems with solaris libpq threading problems.
> 
> For more info:
> http://groups.google.com/groups?q=postgres%20solaris%20D_REENTRANT&hl=en&lr=
> &ie=UTF-8&sa=N&tab=wg
> 
> liam
> 
> -----Original Message-----
> From: psycopg-bounces@...
> [mailto:psycopg-bounces@...] On Behalf Of Richard Moon
> Sent: Wednesday, June 30, 2004 1:45 AM

Re: bytea problems

Im not sure if the problem you are having is similar to the one I had.  When
I was doing large selects in Solaris I would get weird results.  I ended up
fixing the problem with:

Rebuild Postgres with the "-D_REENTRANT" flag.  Im not sure if that will
help you or not, but it fixed my problem.  Its worth a shot possibly.

>From what I understand, with the -D_REENTRANT flag set it defines errno to
be a function call instead of a global variable.  This supposedly fixes many
problems with solaris libpq threading problems.

For more info:
http://groups.google.com/groups?q=postgres%20solaris%20D_REENTRANT&hl=en&lr=
&ie=UTF-8&sa=N&tab=wg

liam

-----Original Message-----
From: psycopg-bounces@...
[mailto:psycopg-bounces@...] On Behalf Of Richard Moon
Sent: Wednesday, June 30, 2004 1:45 AM
To: psycopg@...
Subject: Re: [Psycopg] bytea problems

I'm already using the psycopg.Binary call as you mentioned - After
digging deeper it may well be a problem with libpq and threads on
solaris.

Regards

bug, copy_from does not raise exceptions when failing.

We are using the cursor.copy_from(file, tabname) method a lot and just got
bit hard by the lack of feedback from it.

If the input file for a copy ohas problems such that postgres rejects
the copy, eg missing column, invalid data etc, postgres puts an ERROR
message into the server log and rollsback the copy, but psycopg does
not notice it or report an error or raise an exception. Which makes it
hard to tell if the copy worked. psql by the way reports the error,
so it is sent to the client.

Example:

  in psql:

     create table bad(i int, t text);

  in file bad.in:

1	one
2	two
badint	would have been three

in python:

     # get a connection, cursor and all that
     curs.copy_from(file("bad.in"), "bad")

The copy fails, but no exception is raised.

Re: bug, copy_from does not raise exceptions when failing.

Lì giovedì, 2004/07/01 alle 19:35, -0700, daveg ha scritto:
>      # get a connection, cursor and all that
>      curs.copy_from(file("bad.in"), "bad")
> 
> The copy fails, but no exception is raised.

ouch. i'll look at it this afternoon.

federico

How to realise a "mass" SELECT efficiently?

Hi,

I already search the web, but maybe the keywords were not useful, as
I'm relatively new to databases.

I like to realise a select using a list of binary ids like this:

SELECT * FROM mytable WHERE myid IN ( id[0], id[1], ... )

I hacked this in Python this way, which works so far:

ids = string.join(["%s"] * len(ids), ", ") % \
      tuple(map(psycopg.Binary, ids))
curs.execute("SELECT * FROM " + mytable WHERE myid IN ( " + ids + " )")
rows = curs.dictfetchall()

Unfortunately, this seems to be slow, if the list of ids becomes very
long (e.g. > 1000 or > 5000).  Is there a more efficient way to solve
this problem in psycopg?  Many thanks in advance!

Cheers, WB
http://people.debian.org/~debacle/

Re: How to realise a "mass" SELECT efficiently?

I think this is more of a generic SQL problem than a psycopg one. What I
suggest you do is create a temporary table with a single column with the
IDs you need as keys, then do a inner-join between this temp table and
mytable.

You might realise you just moved the slowdown from the select to the
create (or to the insert after the create), in which case I suggest you
try to find a more efficient way of populating the temp table, like
using 'cursor.copy_from()'.

Then again, if you have this huge number of IDs, maybe you can find a
way to populate the temp table of IDs using database operations.

Hope this helps

Cheers, Leo

On Fri, 2004-07-02 at 16:01, W. Borgert wrote:
> Hi,
> 
> I already search the web, but maybe the keywords were not useful, as
> I'm relatively new to databases.
> 
> I like to realise a select using a list of binary ids like this:
> 
> SELECT * FROM mytable WHERE myid IN ( id[0], id[1], ... )
> 
> I hacked this in Python this way, which works so far:
> 
> ids = string.join(["%s"] * len(ids), ", ") % \

RELEASE: psycopg 1.1.14pre2 (was: "bug, copy_from does not raise exceptions when failing")

Lì giovedì, 2004/07/01 alle 19:35, -0700, daveg ha scritto:
> We are using the cursor.copy_from(file, tabname) method a lot and just got
> bit hard by the lack of feedback from it.

And with release 1.1.14pre2 the feedback is in. :) This is still another
test release because the copy from feedback required some modification
to the notice callback and I don't know if it breaks code out there.
Please test and report any bugs before I release 1.1.14 final. 

Download from:

  http://initd.org/pub/software/psycopg/psycopg-1.1.14pre2.tar.gz

Have fun,
federico

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
INIT.D Developer                                           fog@...
  Those who do not study Lisp are doomed to reimplement it. Poorly.
                                     -- from Karl M. Hegbloom .signature

_______________________________________________
Psycopg mailing list
Psycopg@...
http://lists.initd.org/mailman/listinfo/psycopg

problems with ZPsycopgDA and zope-2-7-0

_______________________________________________
Psycopg mailing list
Psycopg@...
http://lists.initd.org/mailman/listinfo/psycopg