From: | Vlad <marchenko(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org, dbdpg-general(at)gborg(dot)postgresql(dot)org |
Subject: | Re: 'prepare' is not quite schema-safe |
Date: | 2005-05-02 03:01:54 |
Message-ID: | cd70c681050501200144d82448@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom,
thanks for you reply.
> That's what it is supposed to do. It would hardly be possible to
> "prepare" a query at all if we had to wait till EXECUTE to find out
> which tables it was supposed to use.
I understand that from postgresql point of view everything is logical.
>From the application that serves multiple (identical) queries using
the same DB connection and switching the schemas depends of the
account a query came for it turns into oddity with the switch from
DBD::Pg 1.32 (which caches prepared queries internally AFAIK) to
DBD::Pg 1.41 wich has postgresql prepare the query...
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!
--
Vlad
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-02 03:19:16 | Re: 'prepare' is not quite schema-safe |
Previous Message | Vlad | 2005-05-02 02:36:39 | Re: [Dbdpg-general] 'prepare' is not quite schema-safe |