Re: PL/pgSQL 2 - Mailing list pgsql-hackers

On 01/09/14 14:27, Joel Jacobson wrote:
> On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> I agree with Andres - it is not a good for plpgsql and for plpgsql users.
>> The benefit must be significant for 90% of users.
> ...
>> Official implementation of plpgsql2 can be very wrong and dangerous signal -
>> so we should not to do.
> Do you argue the introduction of plpgsql2 would hurt the users of
> plpgsql in some way? How?
>
> If you have X% who continue to happily use plpgsql, and (100-X%) who
> find they can use plpgsql2 in their project, for new functions or all
> functions (for a new project), then you have made (100-X)% of the
> users more happy, than they would be if they were forced to use
> plpgsql and suffer from its problems.
>
> It *would* be a problem if you had to choose between writing all
> functions in their plpgsql or plpgsql2, but thanks to postgres support
> for different pl-languages and mixing different languages in the same
> project, I cannot see the problem.
    What it's clear from my "non-hacker, casual hackers ml reader" 
opinion here, is that there is room for new language features or a new 
in-core language at once. I find Joel's reasoning quite clear about the 
general concepts of improving on plpgsql, although the precise changes 
may not be big enough to justify just a new version. But if there are 
enough changes, and breaking compatibility with the current plpgsql is a 
major concern, I fail to buy other arguments of why doing plpgsql2 is a 
bad thing. The comparisons with Python/Perl are very misleading, as they 
have nothing to do with Postgres, and the case is obviously different.
    What I can add is that, if Postgres is to devote resources to a new 
language, I would plan it with a broader scope. What would attract most 
users? Would it bring non postgres users to Postgres? What could be one 
of the killer features of any next version? My trivial answer to most of 
these questions is: PL/SQL. I don't know with detail how complex this is 
to get in Postgres (well, EDB probably knows), but if I had to chose a 
new language, this is it. So my questions would rather be:

- Is it feasible (resources, time, interest) to implement PL/SQL in 
Postgres?
- Does it support all the requested new features Joel and others 
mentioned in this thread as desires for the new language?
- If the answer to the previous question is no, could those unsupported 
features be implemented as a compatible superset of PL/SQL?
    Sorry if this sounds too unconventional for this list, but this is 
what IMVHO many users would be more pleased with.
    My 2 cents,
    Álvaro