On sön, 2010-02-21 at 11:00 +0100, Pavel Stehule wrote:
> * Now I am working on migration of plpgpsm to plpgsql 9.0 base. I hope
> so I understand SQL/PSM well so I am able to write production quality
> implementation. If you like, I can integrate it to core. It can share
> about 40-50% code with plpgpsm. The behave of plpgpsm is same as
> plpgsql - without some plpgsql's historical issues (about FOUND, about
> NULL and record type). SQL/PSM is litlle bit richer language. Now we
> have not any wide used runtime so I don't thinking about rewriting.
> Maybe we can rewrite these PL language for parrot or lua runtime in
> future. But this step isn't necessary - people hasn't performance
> problems with PL based on PL runtime.
While having a "cleaner" variant of PL/pgSQL available might be
desirable for some (but compare discussion on plpython3), given that you
label this SQL/PSM, I suppose you are also working on this from a
standards-compliance perspective. According to my reading, the part of
the SQL standard that is named SQL/PSM does not, however, describe a
procedural language in the PostgreSQL sense of the term. It describes
server-side modules and an extension to the SQL language (that is, it is
activated by CREATE FUNCTION ... LANGUAGE SQL). It remains to be
decided which parts of these are ultimately useful and desirable, but I
suggest that there be some discussion on the exact strategy in this area
first, lest we end up with a "plpgsql3".