Re: Parsing speed (was Re: pgstats_initstats() cost) - Mailing list pgsql-hackers

From Sean Chittenden
Subject Re: Parsing speed (was Re: pgstats_initstats() cost)
Date
Msg-id 20030812200745.GD82366@perrin.int.nxad.com
Whole thread Raw
In response to Parsing speed (was Re: pgstats_initstats() cost)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Parsing speed (was Re: pgstats_initstats() cost)
List pgsql-hackers
> This leaves us with a bit of a problem, though, because there isn't
> any libpq API that allows access to this speedup.  I put in a
> routine to support Parse/Bind/Execute so that people could use
> out-of-line parameters for safety reasons --- but there's no
> function to do Bind/Execute against a pre-existing prepared
> statement.  (I had to make a hacked version of libpq to do the above
> testing.)
> 
> I'm beginning to think that was a serious omission.  I'm tempted to
> fix it, even though we're past feature freeze for 7.4.  Comments?

On a quasi-similar note (and unless I've missed how to do this), you
can't create a cursor from a prepared statement, which I found
frustrating.  On frequently used queries, I've gotten in the habbit of
preparing the queries at connect time and then executing the query,
but with larger queries, it's problematic to not be able to use a
cursor in addition to the prepared statement.

-sc

-- 
Sean Chittenden


pgsql-hackers by date:

Previous
From: Jon Jensen
Date:
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)
Next
From: Alvaro Herrera Munoz
Date:
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)