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

From Tom Lane
Subject Re: Parsing speed (was Re: pgstats_initstats() cost)
Date
Msg-id 16429.1060721483@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parsing speed (was Re: pgstats_initstats() cost)  (Joe Conway <mail@joeconway.com>)
Responses Re: Parsing speed (was Re: pgstats_initstats() cost)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> 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?

> Seems pretty well isolated. If you're tallying votes, count me as a "yay".

Well, the early voting is running heavily to the 'yea' side.  Let's talk
about what to call the thing.

Pre-7.4 we had "PQexec" (synchronous) and "PQsendQuery" (asynchronous)
to send a plain text query string (Simple Query message in new-FE-protocol-
speak).  I added "PQexecParams" and "PQsendQueryParams" to do
Parse/Bind/Execute, choosing the names on the basis that being able to
pass out-of-line parameters was the primary new thing they were giving
the user.

A Bind/Execute facility would need a pair of routines with signatures
very similar to PQexecParams/PQsendQueryParams --- they'd take a
prepared statement name instead of a query string, and they'd not need
an array of parameter type OIDs, but otherwise the same.  I couldn't
come up with very good names for them though.  Best idea so far is
PQexecPrepared/PQsendQueryPrepared, but maybe someone has a better one?

We could also think about providing an interface to do just Parse,
although this is inessential since you can set up a prepared statement
by PQexec'ing a PREPARE command.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)
Next
From: Stephen Frost
Date:
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)