| From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-18 07:19:38 |
| Message-ID: | 029501c36559$1a23e2c0$2800a8c0@mars |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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.
If we had a Parse function, then we at phpPgAdmin could allow Reports to
contain parameters, and detect as such, and then when they run their report,
they can enter the values for that run.
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-08-18 13:16:37 | Re: failure in latest cvs |
| Previous Message | Christopher Kings-Lynne | 2003-08-18 01:24:20 | failure in latest cvs |