On Tue, Dec 9, 2008 at 8:59 PM, Chris <[EMAIL PROTECTED]> wrote:
> Richard Huxton wrote:
>>
>> WireSpot wrote:
>>>
>>> This mechanism is still not perfect. Technically it is still possible
>>> for race conditions to appear. Apparently (in PHP at least) pg_connect
>>> does persistent connections by
Richard Huxton wrote:
WireSpot wrote:
This mechanism is still not perfect. Technically it is still possible
for race conditions to appear. Apparently (in PHP at least) pg_connect
does persistent connections by default.
Nope - pg_pconnect() does that. Multiple calls to pg_connect() within
the s
WireSpot wrote:
> This mechanism is still not perfect. Technically it is still possible
> for race conditions to appear. Apparently (in PHP at least) pg_connect
> does persistent connections by default.
Nope - pg_pconnect() does that. Multiple calls to pg_connect() within
the same script will give
On Mon, Dec 8, 2008 at 09:17, Tomasz Ostrowski <[EMAIL PROTECTED]> wrote:
> So:
>
> sql_md5 = md5(sql);
> try {
>PREPARE sql_md5 AS sql;
> } catch (SQLException e) {
>if (! e.getSQLState().equals("42P05")) {
>throw e;
>}
> }
> EXECUTE sql_md5;
Yeah, well, li
On 2008-11-20 12:56, WireSpot wrote:
On Thu, Nov 20, 2008 at 10:56, Albe Laurenz <[EMAIL PROTECTED]> wrote:
Do you still need the old prepared statement?
If not, you can simple DEALLOCATE it and then try the PREPARE again.
Yes, I'd like to keep the old statements, that's part of the perks --
Alvaro Herrera wrote:
In this case, why not just prepare all the needed statements at the
first use of the session by the pool software?
In theory yes, but I can't imagine how it could be done in practice.
The pool software is typically a middleware and the application isn't
even awa
Daniel Verite wrote:
> Also contrary to prepared statements, maybe that cache would be shared
> between connections, and that would be excellent, since it fits the
> typical usage pattern of websites: a high-throughput of a small set of
> low-latency queries, fired from pooled connections.
WireSpot wrote:
So it would eliminate the possibility of clashes, but do nothing for
statement reuse.
Agreed.
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 a
On Fri, Nov 21, 2008 at 09:55:11AM +0200, WireSpot wrote:
> 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.
This is somewhat difficult; things to
On Thu, Nov 20, 2008 at 19:19, Daniel Verite <[EMAIL PROTECTED]> 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 handl
Albe Laurenz wrote:
You'll have to find a way to pick or generate unique names for the
prepared statements.
You could check for name collisions and disambiguate with a suffix
or something.
By the way, why do the prepared statements require to be named at all?
With other DBMS such as or
On Thu, Nov 20, 2008 at 16:07, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> I guess if connections are persistent, you could clear them before each
> usage with DISCARD (8.3 only)
Again, I'd be losing the advantage of the already prepared statements.
Basically, what it comes down it is I want to be
On Thu, Nov 20, 2008 at 04:03:08PM +0200, WireSpot wrote:
> On Thu, Nov 20, 2008 at 15:45, Sam Mason <[EMAIL PROTECTED]> wrote:
> > Have you thought about using stored procedures instead of prepared
> > statements? No need to register them or keep track of that state.
>
> I'm not sure if it would
WireSpot escribió:
> I guess he means if connections are persistent, or if the same
> connection is being used at the same time from different parts of the
> application.
I guess if connections are persistent, you could clear them before each
usage with DISCARD (8.3 only)
--
Alvaro Herrera
On Thu, Nov 20, 2008 at 15:45, Sam Mason <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 09:42:33PM +0200, WireSpot wrote:
>> I also imagined some workarounds in the code (PHP), such as defining a
>> global/static hash table and registering statement names with it. But
>> I'd like to know if t
On Wed, Nov 19, 2008 at 09:42:33PM +0200, WireSpot wrote:
> I also imagined some workarounds in the code (PHP), such as defining a
> global/static hash table and registering statement names with it. But
> I'd like to know if there's a better way.
Have you thought about using stored procedures inst
> Merlin Moncure escribió:
>> pg_prepared_statements (on recent versions of postgresql)
Thank you, that's one of the things I wanted to know.
On Thu, Nov 20, 2008 at 15:30, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Merlin Moncure escribió:
>> also, watch out for race conditions.
>
> What race c
Merlin Moncure escribió:
> On Wed, Nov 19, 2008 at 2:42 PM, WireSpot <[EMAIL PROTECTED]> wrote:
> > 3) Reading a list of all the currently defined prepared statements to
> > see if the one I want is already prepared. I'm hoping some "magic"
> > SELECT in pg's internal tables may do the trick. But
Please, send your replies to the list as well.
WireSpot wrote:
> > Do you still need the old prepared statement?
> >
> > If not, you can simple DEALLOCATE it and then try the PREPARE again.
>
> Yes, I'd like to keep the old statements, that's part of the perks --
> if a query will be repeated it
On Wed, Nov 19, 2008 at 2:42 PM, WireSpot <[EMAIL PROTECTED]> wrote:
> I'm trying to use prepared statements in an application and I'm
> running into this error: "Query failed: prepared statement already
> exists".
>
> The reason is obvious. What I want to know is the best way to avoid
> getting th
On Thu, Nov 20, 2008 at 10:56, Albe Laurenz <[EMAIL PROTECTED]> wrote:
> Do you still need the old prepared statement?
>
> If not, you can simple DEALLOCATE it and then try the PREPARE again.
Yes, I'd like to keep the old statements, that's part of the perks --
if a query will be repeated it will
WireSpot wrote:
> I'm trying to use prepared statements in an application and I'm
> running into this error: "Query failed: prepared statement already
> exists".
>
> The reason is obvious. What I want to know is the best way to avoid
> getting this error. The client application sets statement name
I'm trying to use prepared statements in an application and I'm
running into this error: "Query failed: prepared statement already
exists".
The reason is obvious. What I want to know is the best way to avoid
getting this error. The client application sets statement names as MD5
of the actual query
On Sun, Aug 13, 2006 at 10:48:37AM -0700, Jim Bryan wrote:
> Hi! In a function to insert rows into a table, I keep
> getting ERROR: prepared statement "updateplan" already
> exists. If any ideas; thanks.
As the error says, you already have a prepared statement named
"updateplan". To reuse that
Hi! In a function to insert rows into a table, I keep
getting ERROR: prepared statement "updateplan" already
exists. If any ideas; thanks.
CREATE OR REPLACE FUNCTION testPreparedStatement()
RETURNS SETOF FLOAT AS $$
DECLARE
tryint1 int4:=1 ;
tryint2 int4:=2 ;
BEGIN
PREPARE updatePlan
25 matches
Mail list logo
