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" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
