2010/3/1 Peter Eisentraut <peter_e@gmx.net>:
> 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".
>
I invite any discussion. I hope so my implementation will be clean and
fast. Still I am learning this language and have to understand to
core. I afraid so implementation SQL/PSM will be little bit modified -
postgresql use little bit different concept of warnings, and mainly we
have not "procedures". So there will be some new limits. My goal is
creating some prototype now. I am sure so we can better integrate PL
to main parser - but it hasn't be a first step.
Pavel
>