Re: Parsing speed (was Re: pgstats_initstats() cost)

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 13:37:22
Message-ID: 22561.1060781842@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:
>> 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.

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-08-13 13:46:24 Re: 7.4 LOG: invalid message length
Previous Message Bertrand Petit 2003-08-13 12:56:45 7.4 beta 1: SET log_statement=false