Re: [Pypgsql-users] Re: [ANN] pyPgSQL 2.1 released

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

Gerhard =3D?unknown-8bit?Q?H=3DE4ring?=3D wrote:
> * pa...@bo... <pa...@bo...> [2002-06-05 17:08 -0000]:
> > On Wed, 5 Jun 2002 18:40:11 +0200 Gerhard H=E4ring wrote:
> > >CC-ing to pypgsql-users list, maybe other users have comments on thi=
s issu
> e,
> > >too.
> > =

> > [Arrays vs. 'IN']
> > =

> > >QUERY: DECLARE PgSQL_08120A6C CURSOR FOR select * from cages where n=
ame
> > >       in '{"mammals","apes"}'
> > >
> > >... which obviously cannot work. The reason is that if pyPgSQL encou=
nters a
> > >tuple or a list in the statement parameters, it will quote them suit=
able for
> > >use as an ARRAY. Unfortunately, the ARRAY syntax is different from w=
hat you
> > >would need for the IN operator in SQL.
> > =

> > Right, and there's no way of knowing what the database engine expects=
 for
> > that parameter until it has parsed the statement.
> =

> Unless you also parse at the client side, which I'd rather not ;-)
> =

> There might be a solution with controlling the behaviour using a flag i=
n the
> cursor object, for example.

One solution would be to add a new type called pgArray, which would be a =
simple wrapper to the list type that would provide a quote method for cha=
nging it's list into the proper format needed by PostgreSQL for an array.=
  That would free up the list type so that it can be used as in the given=
 example.  This would mean, though, that you would lose the automatic tra=
nslation of a python list to a PostgreSQL array.  This seems a small pric=
e to pay for the benefit gained.

Python 2.2.x new classes would make this rather easy.
-- =

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