Re: Parsing speed (was Re: pgstats_initstats() cost)
От | Tom Lane |
---|---|
Тема | Re: Parsing speed (was Re: pgstats_initstats() cost) |
Дата | |
Msg-id | 16429.1060721483@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Parsing speed (was Re: pgstats_initstats() cost) (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: Parsing speed (was Re: pgstats_initstats() cost)
|
Список | 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 по дате отправления: