| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | 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-13 13:59:33 |
| Message-ID: | 20030813215910.X30109-100000@houston.familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > Wait just a minute! phpPgAdmin would love to be able to 'parse' arbitrary
> > sql entered by the user to separate semi-coloned queries, identify various
> > types of queries, etc. What would a Parse call allow us to do?
>
> Hm. I was about to say "very little that you can't do with a PREPARE",
> but if you don't want to even count semicolons then Parse would be
> distinctly safer. For example if the string is
> SELECT * FROM foo; UPDATE foo SET ...
> then sticking a PREPARE in front would not have the desired effect ---
> but sending it in a Parse message would result in a syntax error.
> Not sure if that helps you get to your goal though.
What do you actually get back from a Parse request?
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-08-13 14:05:13 | Re: set constraints docs page |
| Previous Message | Tom Lane | 2003-08-13 13:46:24 | Re: 7.4 LOG: invalid message length |