I agree with Jan,
As part of my own projects I had to deal with the PL/pgSQL parser.
While it was a workable design at the beginning, it now makes some
things harder with the quoting etc.
Don't get me wrong, I've never really had any beef with PL/pgSQL, it has
worked great for a long time but I think it could definitely use a rewrite.
I don't recommend discussion for this in this thread, but it could also
tie in with the packages support we've discussed and (although some may
argue this), compiling the PL to bytecode and using that.
-Jonah
Jan Wieck wrote:
> 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
>