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

From Álvaro Hernández Tortosa
Subject Re: PL/pgSQL 2
Date
Msg-id 5404E115.60507@nosys.es
Whole thread Raw
In response to Re: PL/pgSQL 2  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: PL/pgSQL 2
List pgsql-hackers

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



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

On 01/09/14 20:42, Tom Lane wrote:
Álvaro Hernández Tortosa <aht@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 incompatibilities
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?

    Regards,

    Álvaro


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: [BUGS] Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns
Next
From: Álvaro Hernández Tortosa
Date:
Subject: Re: PL/pgSQL 2