From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, 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-13 14:32:14 |
Message-ID: | 23741.1060785134@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-08-13 15:19:58 | Re: set constraints docs page |
Previous Message | Tom Lane | 2003-08-13 14:05:13 | Re: set constraints docs page |