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
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 |