Re: prepared statements and DBD::Pg

From: JP Fletcher <jpfletch(at)ca(dot)afilias(dot)info>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, David Fetter <david(at)fetter(dot)org>, Andrej <andrej(dot)groups(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: prepared statements and DBD::Pg
Date: 2009-05-08 21:01:51
Message-ID: 4A049DBF.7000302@ca.afilias.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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); INSERT
> INTO foo(2, 2);")
>>
>> My argument is that both calls should return statement handles.
>
> I think they do, and the original report is somehow flawed.
In my attempt to obfuscate the actual code, I actually included invalid
SQL , but I can assure you that the failure occurred as I described it,
though only with the version 2.11.8. Other versions > 1.4 worked fine,
despite the explanation in the DBD::Pg docs which implied that they
might not.

> Here's a test that demonstrates this with the SQL pasted from the
> initial example.
>
> print "version is $DBD::Pg::VERSION\n";
> $dbh->{pg_server_prepare} = 1;
> my $prepare_sql =<<SQL;
> CREATE TEMP TABLE foo( id int, user_id int,);
>
> INSERT INTO foo(1, 1);
>
> INSERT INTO foo(2, 2);
> SQL
> my $sth1=$dbh->prepare($prepare_sql);
> print "1st statement handle=$sth1\n";
> $prepare_sql=<<SQL;
> INSERT INTO foo(1, 1);
>
> INSERT INTO foo(2, 2);
> SQL
> my $sth2=$dbh->prepare($prepare_sql);
> print "2nd statement handle=$sth2\n";
>
> And here's the output I get:
> version is 2.8.2
> 1st statement handle=DBI::st=HASH(0x8d40908)
> 2nd statement handle=DBI::st=HASH(0x8c73660)
>
>> If a server-side prepare is attempted and fails because it's a kind
> of
>> statement that can't be server-side prepared then DBD::pg should
>> fallback to a client-side prepare.
>
> Unfortunately with PG, an error in server-side prepare aborts the
> current transaction, so that any subsequent command will fail until a
> rollback is issued. Falling back to client-side prepare once in this
> state would probably not help much.
>
> Best regards,

--
JP Fletcher
Database Administrator
Afilias Canada
voice: 416.646.3304 ext. 4123
fax: 416.646.3305
mobile: 416.561.4763
jpfletch(at)ca(dot)afilias(dot)info

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Emanuel Calvo Franco 2009-05-08 21:10:18 limit-offset different result sets with same query
Previous Message Daniel Verite 2009-05-08 19:52:45 Re: prepared statements and DBD::Pg