Re: Prepared statement already exists

From: WireSpot <wirespot(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Prepared statement already exists
Date: 2008-11-21 07:55:11
Message-ID: b2d4b0380811202355h1146c6acu6c7d2e929828b865@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Nov 20, 2008 at 19:19, Daniel Verite <daniel(at)manitou-mail(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2008-11-21 07:56:51 Re: Serial - last value
Previous Message Sergey Moroz 2008-11-21 07:49:22 transaction isolation level in plpgsql function