Skip site navigation (1) Skip section navigation (2)

Re: DBD::Pg 2.0.0 release candidate available for testing

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: dbd-pg(at)perl(dot)org
Cc: dbi-users(at)perl(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: DBD::Pg 2.0.0 release candidate available for testing
Date: 2008-01-17 15:57:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
Hash: RIPEMD160

>> * Full support for arrays: Perl arrays are transformed to Postgres
>> arrays automatically, and vice-versa.

> I presume this is "array type stored in a column",
> not "array for bulk loading" ?


> Does Pg support native array binding of tuples yet ? The docs could be
> a bit confusing. E.g., I'm not certain what "Supported by this driver
> as proposed by DBI." means ? You may want to clarify that bit, and the
> difference between "bind array to a column" vs. "binding an array
> of parameters")

It does both, if I am understanding you correctly. That is, you can do:

$sth->execute([1,2,3]); ## or more nested

as well as:

$sth->bind_param_array(1, [ 30, 31, 32 ], SQL_INTEGER);

...which do very different things, of course.

> Esp., does the COPY IN support native array binding (not the DBI
> default iterator) ?

Don't follow you at all here, but I suspect the answer is "no"
if you mean putting pg_getcopydata into an arrayref.

>> * Asynchronous queries, which let's you start a query, go off and do
>> other things, and check back to see if it has finished, and fetch the
>> data when you are ready to. This also allows you to cancel running queries.

> BTW: Do you have any examples that are "smarter" about
> testing ready() ? I.e., grab the Pg socket, do a select() or poll(),
> and only call ready() when there's activity on the socket ?

No, I've left that as an exercise to the reader, or in this case, the
application writer. :) Should be easy enough to modify the example here:

Doc patches always welcome, naturally.

> I've implemented a driver-specific function in DBD::Teradata to
> do that internally (essentially, a select() for $dbh's + other filehandles).
> Might be something to consider for Pg (I'd suggest support
> at the DBI layer, except some drivers (e.g., ODBC) may not have access
> to the underlying communication channel.

I wouldn't let that stop you - there are lots of bits of DBI that are
not usable and/or implemented by various DBDs, right? I'd also love
to see some more standardizing and eventually deprecate as many of the
pg_* functions as we can.

Thanks for the feedback

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200801171054


In response to

pgsql-interfaces by date

Next:From: fschmidtDate: 2008-01-24 18:18:05
Subject: Is there an interface that...
Previous:From: Max PyziurDate: 2008-01-16 17:59:27
Subject: Re: Multiple command usage in DBD-Pg v 1.49

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group