Re: PL/pgSQL 2

From: Álvaro Hernández Tortosa <aht(at)nosys(dot)es>
To: Marko Tiikkaja <marko(at)joh(dot)to>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PL/pgSQL 2
Date: 2014-09-02 10:55:35
Message-ID: 5405A227.5080804@nosys.es
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 02/09/14 12:46, Marko Tiikkaja wrote:
> On 9/2/14 11:40 AM, Álvaro Hernández Tortosa wrote:
>> 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.
>
> Have you looked at
> http://www.postgresql.org/docs/9.3/static/plpgsql-porting.html already?

Precisely this page shows some indications of examples of things
that could be done at a language level that would make it way easier to
port from PL/SQL (if you don't use that unsupported stuff). At least for
that, if the syntax is exactly the same, it could make things much more
comfortable (I'm not aiming for a 0-effort port, at least in first
place, but to get the 80% or 60% easier than now).

> As far as I can tell, that already *is* the case as far as the
> language goes. It seems to me that most of the stuff that's different
> between the two are things that are out of the control of the language
> (no autonomous transactions, function source code in a literal etc.)

Maybe it would be interesting to analyze:

- What it's impossible to have right now in postgres
- What can be implemented in a different way, but that would work in
postgres
- What could be somehow emulated

And adapt the syntax as much as possible to aim for the biggest
compatibility possible.

>
>> 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.
>
> This would be a horrible, horrible lie.

Certainly not more horrible than today's "PostgreSQL has NoSQL".
Despite that, I'm not saying I'd lie. I'd say what the media would say,
which is completely different.

>
>> 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.
>
> The best part about PL/PgSQL is the seamless integration with SQL.
> You can put an SQL expression pretty much anywhere. How well would
> that work if the "framework" was Javascript instead of the ADA-like
> body that both PL/SQL and PL/PgSQL implement?

SQL integration is a must in a PL/* language, that's for sure. But
leveraging a well known language, tooling, and, specially, external
libraries/ecosystem is a much bigger win. Specially if all the languages
that I know of are capable (with more or less effort) to integrate SQL.
So maybe JavaScript with a way of integrating SQL would be preferable IMO.

Regards,

Álvaro

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-09-02 11:11:46 Re: pgsql: Compress GIN posting lists, for smaller index size.
Previous Message Marko Tiikkaja 2014-09-02 10:46:10 Re: PL/pgSQL 2