Re: Implementing SQL/PSM for PG 8.2

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: Implementing SQL/PSM for PG 8.2
Дата
Msg-id 42C04E8F.2020103@Yahoo.com
обсуждение исходный текст
Ответ на Re: Implementing SQL/PSM for PG 8.2  (Pavel Stehule <stehule@kix.fsv.cvut.cz>)
Ответы Re: Implementing SQL/PSM for PG 8.2  ("Jonah H. Harris" <jharris@tvi.edu>)
Re: Implementing SQL/PSM for PG 8.2  (Neil Conway <neilc@samurai.com>)
Список pgsql-hackers
On 6/26/2005 4:10 PM, Pavel Stehule wrote:

> On Sun, 26 Jun 2005, Tom Lane wrote:
> 
>> "Denis Lussier" <denis@enterprisedb.com> writes:
>> > For various technical and backward compatibility reasons, I don't think
>> > SQL/PSM should be a replacement for PL/pgSQL.  Although I do think it
>> > should heavily leverage the solid foundation afforded by the PL/pgSQL
>> > code base.
>> 
>> "Solid"?  I've wanted for quite some time to throw away plpgsql and
>> start over --- there are too many things that need rewritten in it,
>> starting with the parser.  This project would be a great place to do
>> that.
>
> What is wrong on plpgsql code? I see some problems with processing SQL 
> statements, with efectivity evaluation of expr, but parser is clean (in my 
> opinion). 

The whole parser is a hack that attempts to parse the procedural parts 
of the function but preserving the SQL parts as query strings while 
substituting variables with numbered parameters. That is anything but 
clean. It was the only way I saw at the time of implementation to build 
a parser that automatically supports future changes of the main Postgres 
query language. But that doesn't mean that I like the implementation.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


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

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: tsearch2 vs core?
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Problem with dblink regression test