Re: Parsing speed (was Re: pgstats_initstats() cost)
От | Tom Lane |
---|---|
Тема | Re: Parsing speed (was Re: pgstats_initstats() cost) |
Дата | |
Msg-id | 23741.1060785134@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Parsing speed (was Re: pgstats_initstats() cost) (Christopher Kings-Lynne <chriskl@familyhealth.com.au>) |
Ответы |
Re: Parsing speed (was Re: pgstats_initstats() cost)
|
Список | pgsql-hackers |
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > What do you actually get back from a Parse request? Nothing. If successful, it creates a prepared statement inside the server. It might possibly make sense for a libpq routine that exposes Parse to actually do Parse followed by Describe Statement; that would allow it to give back (a) an indication of the number and types of parameters needed by the statement, and (b) an indication of the column set to be returned, if it's a SELECT. However, the protocol doesn't tell anything about the type of a non-SELECT statement. In any case, this would require more invention and coding than I care to do at this point in the release cycle (since there's no support in the guts of libpq for accepting ParameterDescription messages from the backend). If that's what we think we want, we'd better put it on the wish-list for 7.5. regards, tom lane
В списке pgsql-hackers по дате отправления: