From: | Sean Chittenden <sean(at)chittenden(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Parsing speed (was Re: pgstats_initstats() cost) |
Date: | 2003-08-12 20:07:45 |
Message-ID: | 20030812200745.GD82366@perrin.int.nxad.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera Munoz | 2003-08-12 20:10:22 | Re: Parsing speed (was Re: pgstats_initstats() cost) |
Previous Message | Jon Jensen | 2003-08-12 20:05:58 | Re: Parsing speed (was Re: pgstats_initstats() cost) |