Re: Parsing speed (was Re: pgstats_initstats() cost)

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

In response to

Responses

Browse pgsql-hackers by date

  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)