On 01/09/14 21:08, Pavel Stehule wrote:

2014-09-01 20:58 GMT+02:00 Álvaro Hernández Tortosa <a...@nosys.es <mailto:a...@nosys.es>>:

    On 01/09/14 20:42, Tom Lane wrote:

        =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= <a...@nosys.es
        <mailto:a...@nosys.es>> writes:

                  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.

        By that I suppose you mean "I wish it would act just like Oracle".
        The problem with such a wish is that a lot of the
        with Oracle are functions of the core SQL engine, not of the PL.
        plpgsql already is about as close to PL/SQL as it's possible
        to get
        without changing core Postgres behavior --- or at least, that was
        the original design desire, and I don't think that it's failed in
        any large degree.

                                regards, tom lane

        It's true that some of the incompatibilities are the core
    engine, internal functions and so on, and that the plpgsql design
    goal was to achieve "similarity". But similarity is not code
    compatibility, and afaik, plpgsql is not code compatible with
    PL/SQL. Having 1:1 code compatibility, if possible, is a very well
    first step, only followed by the core functionalities you mention.

        If postgres were going for a new language, why not implement
    one which, having the other suggested functionality, also has 1:1
    PL/SQL code compatibility? I'm sure it's no trivial task, but one
    highly desirable.

It is false expectation - language is only one part .. and plpgsql isn't to far. There are different system of modules, different system of custom aggregates, mainly with PL/SQL is very complex library dbms_xxxx. This library is maybe more complex than current Postgres base.

OK. Understood. Full compatibility may be a longer-term goal. But why it's bad to have the same syntax at a language -not library- level?

It is task for commercial project --- not all Postgres users need a Oracle compatibility layer.

Certainly not all users need that layer. But I'm sure few would complain to have it.

Besides that, why do you say it is meant for a commercial project? If it is because postgres should not listen to users willing to migrate from Oracle --then we're screwed, losing the biggest opportunity (of attracting a large crowd of users) of recent times. If it is because it's too complex... well, I don't think the postgres community (as a whole) have less resources than commercial projects.

Next, I am sure, so it is in contradiction to Joel proposal.

    That's not my business ;P

No, really: if there is a new version of a "language", which modifies the current syntax of plpgsql; if plpgsql is already very similar to PL/SQL: why not rather than coming up with a new syntax use an already existing one? One that many, many more users than plpgsql, already know?



Reply via email to