ok, since there is no gurantee that server-side prepared query is
still active, pergaps postgresql interface library provide way to
check if a prepared before query still alive prior runing exec, so
that dbd::pg driver can make sure it's still there, right before
executing?
If there is no such function (and I can't find it), then it will be
hard for a driver to make things working right with server-side
prepared queries!
On 5/2/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vlad <marchenko@gmail.com> writes:
> > so is it possible that a successfully prepared (and possibly a couple
> > of times already executed) query will be invalidated by postgresql
> > for some reason (like lack of memory for processing/caching other
> > queries)? Assuming that no database structure changes has been
> > performed.
>
> Well, that assumption is wrong to start with: what if the query plan
> uses an index that someone else has chosen to drop? Or the plan
> depends on an inlined copy of a SQL function that someone has since
> changed? Or the plan was chosen on the basis of particular settings
> of planner parameters like random_page_cost, but the user has changed
> these via SET? (The last is a pretty close analogy to changing
> search_path, I think.)
>
> 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 of
> these situations :-(
>
--
Vlad