Greg,
thanks for the suggestion. looking into other thread on the list, it
looks like setting
$dbh->{pg_server_prepare} = 0;
would solve my problem as well. With this setting will dbd::pg behave
in old-style (i.e. prepare_cached prepared and stored on dbd::pg
side), or it won't cache anything at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> Which is why Vlad should use prepare() instead of prepare_cached().
> in our web application similar SQL queries (like load an object)
> executed over and over again with high frequency. So it's very
> desirable to use prepare_cached. I think we
On May 2, 2005, at 11:51 , Vlad wrote:
in our web application similar SQL queries (like load an object)
executed over and over again with high frequency. So it's very
desirable to use prepare_cached. I think we are going to adjust our
ORM (object relation mapper) to always use full path to referenc
> > The docs for prepare_cached() are littered with "Don't do this unless
> > you understand the implications" warnings, as well as some kludges to
> > differentiate different cases.
>
> Which is why Vlad should use prepare() instead of prepare_cached().
in our web application similar SQL queries
On May 2, 2005, at 09:34 , Tom Lane wrote:
I think you could demonstrate that if the spec is "make it look
like the
original query was retyped as source each time", then *every* DDL
change
in the database potentially requires invalidating every cached plan.
I don't find that a desirable spec.
I
On May 1, 2005, at 23:16 , Steve Atkins wrote:
Isn't this behaving as documented? prepare_cached() is supposed to
return the original statement handle when you pass it the same string
a second time.
Yes.
The docs for prepare_cached() are littered with "Don't do this unless
you understand the implic
David Wheeler <[EMAIL PROTECTED]> writes:
> On May 1, 2005, at 21:30 , Neil Conway wrote:
>> An alternative would be to flush dependent plans when the schema
>> search path is changed. In effect this would mean flushing *all*
>> prepared plans whenever the search path changes: we could perhaps
On May 1, 2005, at 21:30 , Neil Conway wrote:
An alternative would be to flush dependent plans when the schema
search path is changed. In effect this would mean flushing *all*
prepared plans whenever the search path changes: we could perhaps
keep plans that only contain explicit namespace ref
On May 2, 2005, at 06:40 , Andrew Dunstan wrote:
I am not sure this is reasonably fixable. Invalidating the cache is
not a pleasant solution - the query might not be affected by the
change in search path at all. I'd be inclined to say that this is
just a limitation of prepare_cached() which s
On May 2, 2005, at 06:36 , Vlad wrote:
as I understood Tom's message, he's not advising dbd::pg driver to
rely on the fact that earlier prepared query is still valid.
That's not going to change. It's your responsibility, as the
programmer, to know when you need to expire the cache:
$dbh->do("SET
On May 2, 2005, at 06:14 , Neil Conway wrote:
I'm not sure I quite follow you -- in some future version of the
backend in which prepared queries are invalidated, this would be
invisible to the client. The client wouldn't need to explicitly
check for the "liveness" of the prepared query, they
On May 1, 2005, at 22:44 , Tom Lane wrote:
I am not claiming that the backend handles all these cases nicely
today: it certainly doesn't. But we understand in principle how
to fix these problems by invalidating plans inside the backend.
I don't see how the DBD::Pg driver can hope to deal with any
Andrew Dunstan wrote:
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_cach
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
14 matches
Mail list logo
