Re: Prepared statement already exists - Mailing list pgsql-general

From WireSpot
Subject Re: Prepared statement already exists
Date
Msg-id b2d4b0380811202355h1146c6acu6c7d2e929828b865@mail.gmail.com
Whole thread Raw
In response to Re: Prepared statement already exists  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: Prepared statement already exists
Re: Prepared statement already exists
List pgsql-general
On Thu, Nov 20, 2008 at 19:19, Daniel Verite <daniel@manitou-mail.org> wrote:
> By the way, why do the prepared statements require to be named at all?
> With other DBMS such as oracle or mysql, one can prepare statements without
> providing any name for them: the prepare() step returns a "statement handle"
> that is to be passed to subsequent exec() calls, no unique name is involved.

Isn't this basically the same thing? Except instead of having to take
care yourself about the uniqueness aspect, it gets taken care of
automatically by the language, since each handle becomes a separate
variable.

> Currently with pg, using prepared statements more or less implies
> implementing an application-wide policy about naming them, otherwise there
> is always the risk that some code upper in the stack has a live statement
> with the same name. And what about contributed code or libraries? That would
> be easier if this global namespace for prepared statements didn't exist in
> the first place.

Yeah, but if you wanted to reuse a statement you'd still have to
implement a mechanism in the code. Like in my case, I'd still have to
have a method of recognizing the same query, so I'd still resort to a
hashtable with MD5's as keys, only instead of a boolean I'd put
statement handles in there.

So it would eliminate the possibility of clashes, but do nothing for
statement reuse.

What would make it all the way better was if the database would do
that last step for you as well: automatically recognize statements
that do the same thing and return the already existing handle.

Only then I'd be truly worry-free as far as the code goes; I could
prepare statements left and right knowing that both clashing and reuse
are taken care of by Postgres.

pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: start/stop error message
Next
From: Richard Huxton
Date:
Subject: Re: Serial - last value