Re: PL/pgSQL 2

On 01/09/14 21:08, Pavel Stehule wrote:
>
>
>
> 2014-09-01 20:58 GMT+02:00 Álvaro Hernández Tortosa <aht(at)nosys(dot)es
> <mailto:aht(at)nosys(dot)es>>:
>
>
> On 01/09/14 20:42, Tom Lane wrote:
>
> =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= <aht(at)nosys(dot)es
> <mailto:aht(at)nosys(dot)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