Skip site navigation (1) Skip section navigation (2)

Re: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries
Date: 2010-03-01 20:51:25
Message-ID: 162867791003011251r7e4b7af7x8c5ac40aa5f3b18b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2010/3/1 Peter Eisentraut <peter_e(at)gmx(dot)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

>

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2010-03-01 20:58:44
Subject: Re: double and numeric conversion
Previous:From: Jaime CasanovaDate: 2010-03-01 20:30:20
Subject: Re: function side effects

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group