Re: [Dbdpg-general] Re: 'prepare' is not quite schema-safe

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Vlad <marchenko(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org, dbdpg-general(at)gborg(dot)postgresql(dot)org
Subject: Re: [Dbdpg-general] Re: 'prepare' is not quite schema-safe
Date: 2005-05-02 13:31:11
Message-ID: 42762B9F.40003@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Vlad wrote:

>
>i.e. the following perl code won't work correctly with DBD::Pg 1.40+
>
>$dbh->do("SET search_path TO one");
>my $sth1 = $dbh->prepare_cached("SELECT * FROM test WHERE item = ?");
>$sth1->execute("one");
>
>$dbh->do("set search_path to two");
>my $sth2 = $dbh->prepare_cached("SELECT * FROM test WHERE item = ?");
>$sth2->execute("two");
>
>in the last call $sth1 prepared query will be actually executed, i.e.
>"one.test" table used, not "two.test" as a programmer would expect!
>
>

Correctness seems to be in the eye of the beholder.

It does what I as a programmer would expect. The behaviour you
previously saw was an unfortunate byproduct of the fact that up to now
DBD::Pg has emulated proper prepared statements, whereas now it uses
them for real. Any application that relies on that broken byproduct is
simply erroneous, IMNSHO.

If you really need this, then as previously discussed on list, there is
a way to turn off use of server-side prepared statements.

cheers

andrew

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vlad 2005-05-02 13:36:05 Re: 'prepare' is not quite schema-safe
Previous Message Sean Davis 2005-05-02 13:23:31 Re: Persistent Connections in Webserver Environment