-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
It's perfectly valid (from the DBI's point of view) for prepare() to
return a prepared statement handle for an invalid statement.
On Thu, May 07, 2009 at 06:08:12PM -0700, David Fetter wrote:
On Fri, May 08, 2009 at 01:02:04AM +0100, Tim Bunce wrote:
On Thu, May 07, 2009 at 06:50:11AM -0700, David Fetter wrote:
On Thu, May 07, 2009 at 02:31:08PM +0100, Tim Bunce wrote:
On Thu, May 07, 2009 at 04:54:06AM +1200,
Tim Bunce wrote:
So you're okay with breaking previously working, and prefectly valid,
DBI code?
I think the rationale is that such code was working by virtue of how
prepare() was implemented in DBD::Pg, but was not valid nonetheless,
as outlined with this example:
On Fri, May 08, 2009 at 09:44:56AM +0100, Tim Bunce wrote:
On Thu, May 07, 2009 at 06:08:12PM -0700, David Fetter wrote:
On Fri, May 08, 2009 at 01:02:04AM +0100, Tim Bunce wrote:
On Thu, May 07, 2009 at 06:50:11AM -0700, David Fetter wrote:
On Thu, May 07, 2009 at 02:31:08PM +0100, Tim
On Fri, May 08, 2009 at 04:02:29PM +0200, Daniel Verite wrote:
Tim Bunce wrote:
So you're okay with breaking previously working, and prefectly valid,
DBI code?
I think the rationale is that such code was working by virtue of how
prepare() was implemented in DBD::Pg, but was not
Tim Bunce wrote:
The example that started this thread was that this valid statement
worked:
prepare(CREATE TEMP TABLE foo(...); INSERT INTO foo(1, 1); INSERT
INTO foo(2, 2);)
but this valid statement didn't:
prepare( INSERT INTO foo(1, 1); INSERT
INTO foo(2, 2);)
My
Daniel Verite wrote:
Tim Bunce wrote:
The example that started this thread was that this valid statement
worked:
prepare(CREATE TEMP TABLE foo(...); INSERT INTO foo(1, 1); INSERT
INTO foo(2, 2);)
but this valid statement didn't:
prepare( INSERT INTO foo(1, 1);
On Thu, May 07, 2009 at 04:54:06AM +1200, Andrej wrote:
2009/5/7 JP Fletcher jpfle...@ca.afilias.info:
Hi,
I see different behavior with DBI/DBD::Pg (1.607/2.11.8, pg 8.1) when the
first command in a prepared statement is 'CREATE TEMP TABLE'.
For instance, this works:
my
On Thu, May 07, 2009 at 02:31:08PM +0100, Tim Bunce wrote:
On Thu, May 07, 2009 at 04:54:06AM +1200, Andrej wrote:
2009/5/7 JP Fletcher jpfle...@ca.afilias.info:
Hi,
I see different behavior with DBI/DBD::Pg (1.607/2.11.8, pg 8.1) when the
first command in a prepared statement is
On Thu, May 07, 2009 at 06:50:11AM -0700, David Fetter wrote:
On Thu, May 07, 2009 at 02:31:08PM +0100, Tim Bunce wrote:
On Thu, May 07, 2009 at 04:54:06AM +1200, Andrej wrote:
WARNING: DBD::Pg now (as of version 1.40) uses true prepared
statements by sending them to the backend to be
On Fri, May 08, 2009 at 01:02:04AM +0100, Tim Bunce wrote:
On Thu, May 07, 2009 at 06:50:11AM -0700, David Fetter wrote:
On Thu, May 07, 2009 at 02:31:08PM +0100, Tim Bunce wrote:
On Thu, May 07, 2009 at 04:54:06AM +1200, Andrej wrote:
WARNING: DBD::Pg now (as of version 1.40) uses
Hi,
I see different behavior with DBI/DBD::Pg (1.607/2.11.8, pg 8.1) when
the first command in a prepared statement is 'CREATE TEMP TABLE'.
For instance, this works:
my $prepare_sql =SQL;
CREATE TEMP TABLE foo( id int, user_id int,);
INSERT INTO foo(1, 1);
INSERT
On May 6, 2009, at 9:39 AM, JP Fletcher wrote:
Hi,
I see different behavior with DBI/DBD::Pg (1.607/2.11.8, pg 8.1)
when the first command in a prepared statement is 'CREATE TEMP TABLE'.
For instance, this works:
my $prepare_sql =SQL;
CREATE TEMP TABLE foo( id int, user_id int,);
2009/5/7 JP Fletcher jpfle...@ca.afilias.info:
Hi,
I see different behavior with DBI/DBD::Pg (1.607/2.11.8, pg 8.1) when the
first command in a prepared statement is 'CREATE TEMP TABLE'.
For instance, this works:
my $prepare_sql =SQL;
CREATE TEMP TABLE foo( id int, user_id int,);
14 matches
Mail list logo
