On 01/09/14 14:27, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule <pavel.steh...@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,


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to