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

From Álvaro Hernández Tortosa
Subject Re: PL/pgSQL 2
Date
Msg-id 5405908C.90603@nosys.es
Whole thread Raw
In response to Re: PL/pgSQL 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PL/pgSQL 2
Re: PL/pgSQL 2
List pgsql-hackers
On 02/09/14 06:40, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> If someone came up with a convincing PL/SQL compatibility layer then
>> it'd be worth considering adopting - when it was ready. But of course,
>> anyone who does the work for that is quite likely to want to sell it to
>> cashed-up Oracle users looking to save a few hundred grand on per-CPU
>> licensing.
> As a case in point, EDB have spent quite a few man-years on their Oracle
> compatibility layer; and it's still not a terribly exact match, according
> to my colleagues who have looked at it.  So that is a tarbaby I don't
> personally care to touch ... even ignoring the fact that cutting off
> EDB's air supply wouldn't be a good thing for the community to do.
>
>             regards, tom lane
>
>
    OK, so this compatibility layer is tough. Knew that already ;) But 
on the other side, the syntax is similar to plpgsql, right? So what 
about just having a compatible syntax? It would be the first step to 
that compatibility layer, which could -or could not- be a long-term goal 
for postgres (having the whole layer).
    I don't buy that having that would cut EDB's air supply. They're 
doing great, and they know how to take care of themselves, I'm sure ;) 
Besides that, "competition" is always positive, and I'm sure they'd be 
more benefited than harmed by postgres having that layer.
    If we are to have another plpgsql-like language (like plpgsql2) and 
we could design it so it would attract many many users (let's not forget 
that Oracle may have around two orders of magnitude more users than pg), 
that would benefit us all greatly. Even if not perfect. Even if it is a 
longer project which spans more than one release. But just having the 
syntax (or most of it, maybe avoiding some complex unimplemented 
postgres features, if that required a huge effort) is a big win.
    For 9.4, we have the media already saying "Postgres has NoSQL 
capabilities" (which is only partially true). For x.y we could have the 
media saying "Postgres adds Oracle compatibility" (which would be only 
partially true). But that brings a lot of users to postgres, and that 
helps us all.
    And also.... it could serve as a motivation point to implement 
those in-core missing features, too, that Oracle has.
    If on the other hand we resign from attracting Oracle users, in a 
moment where non-Oracle databases are fighting for them..... and we lose 
here.... well, let's at least have a very compelling, attractive, 
in-core, blessed, language. Even disliking it myself, PL/JavaScript 
would be my #1 candidate there.
    My 4 (already) cents,
    Álvaro



pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: PL/pgSQL 2
Next
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL 2