Re: PL/pgSQL 2

On Tue, Sep 2, 2014 at 7:08 PM, Jan Wieck <jan(at)wi3ck(dot)info> wrote:

> On 09/02/2014 06:56 PM, Andrew Dunstan wrote:
>
>> People are free to do what they want, but to my mind that would be a
>> massive waste of resources, and probably imposing a substantial extra
>> maintenance burden on the core committers.
>>
>
> I hear you and agree to some degree.
>
> But at the same time I remember that one of the strengths of Postgres used
> to be to be able to incorporate "new" ideas.
>
> This seems to be one of those cases.
>
> Instead of "fork" plpgsql2, what about designing a completely new
> PL/postgres from scratch? It will only take 3-10 years, but I bet it will
> be worth it after all. And I mean that. No sarcasm.

Indeed. That seems like a better approach to me.

The notion of hacking features onto plpgsql2 that mostly seem like SQL
enhancements is a waste of time.

I see a few places that look like they might be worth thinking about as
part of a "new thing"; it's important that they not merely be minor tweaks
of the "old thing" otherwise we might as well just improve pl/pgsql.
(That's no bad idea, to be sure!)

1. A classic place where I have leaped to other languages has been to do
sophisticated "string smashing." Often pl/perl, but when that proved
troublesome to run on AIX, I was perfectly happy to port to pl/tcl. My
idle waggish thought over the years has been to consider pl/snobol or
pl/icon. It's conceivable that some improvement to the Postgres built-in
string functions might make this unnecessary. That's worthy of
exploration. (And implementing pl/snobol is probably not! :-))

2. People have been pointing out that EXECUTE isn't all that wonderful. I
think it is no coincidence that in all the languages that have an EVAL, it
is considered poor form to make unnecessary use of it. (True whether we're
talking about Common Lisp or Perl!) The discussion of using FORMAT() to
generate "execute fodder" fits with this. It is again quite plausible that
having some improved functions might make it unnecessary to go all the way
to the extent of implementing a new language.

3. Is there anything to be learned from Tutorial D? That is, Date &
Darwen's would-be alternative to SQL of their Third Manifesto?

4. All the existing stored function languages run inside a transaction
context. I'd sure like it if I could have a platform, running on the
database, which could invoke and control transactions. A layer that can
open connections, manage transactions, and such ought to be mighty useful.
That CANNOT be implemented as one of the existing pl/whatevers.

To justify a new language requires having some requirements that cannot be
fulfilled by cleaning up an existing thing.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"