Re: PL/pgSQL 2

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Steven Lembark <lembark(at)wrkhors(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL 2
Date: 2014-10-07 18:24:21
Message-ID: CAHyXU0zKD2mEwNP3XpgUTYYB3zyU6kcnfjih2+c=sjwLZZZw2g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 7, 2014 at 12:42 PM, Steven Lembark <lembark(at)wrkhors(dot)com> wrote:
> On Mon, 1 Sep 2014 15:19:41 +0200
> Joel Jacobson <joel(at)trustly(dot)com> wrote:
>
>> The fatal problems with Python3 and Perl6 was the inability to mix
>> code between Python2/3 and Perl5/6.
>> We don't have that problem with pl-languages in postgres, so please
>> don't make that comparison, as it's incorrect.
>
> Actually Perl6 can include Perl5 code allows you to "use v5.6" or "use
> v6.0" to regulate how the code in any one block is compiled w/in the
> program. Even Perl 5 allows mixing blocks/modules with different version
> syntax w/in the same compiler.

I don't think that really helps very much at the end of the day; Perl
6 was a disaster for Perl. Breaking compatibility of a language is a
good way to kill it off. Compiler support is only one example of a
very broad set of problems it causes. Hiding that compatibility
breaking under "language 2.0" doesn't solve anything either.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-10-07 18:25:19 Re: Promise index tuples for UPSERT
Previous Message Rodolfo Campero 2014-10-07 18:08:27 Re: PL/pgSQL 2