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: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
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-02-22 15:31:45
Message-ID: 162867791002220731i213a90fbha9d7f03b931bc0a4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/2/22 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Pavel Stehule escribió:
>> Hello,
>>
>> * 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.
>
> How do you plan to go about code sharing?  I'm wondering if we're going
> to have src/pl/common or something like that.  Since there's a huge
> amount of common code it doesn't make any sense to keep it duplicate.

sure - a there a a few parts - simple query diagnostic, namespace
support. Now I would to migrate to 9.0 and have initial version. This
version and regress tests can be used as "etalon". Next stage can be
code cleaning and migration to shared code.

Pavel

>
> Also, AFAIR that was the main rejection point for the plpgpsm patch last
> time around, so it would be good to discuss this thoroughly.
>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-02-22 15:32:17 Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Previous Message Tom Lane 2010-02-22 14:53:59 Re: Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after