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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Parsing speed (was Re: pgstats_initstats() cost)
Дата
Msg-id 22561.1060781842@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)  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Список pgsql-hackers
"Christopher Kings-Lynne" <chriskl@familyhealth.com.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 isSELECT * 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: reuse sysids security hole?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 7.4 LOG: invalid message length