Re: PL/pgSQL 2 - Mailing list pgsql-hackers
| From | Christopher Browne |
|---|---|
| Subject | Re: PL/pgSQL 2 |
| Date | |
| Msg-id | CAFNqd5U1XbMitZduX8cM3RsXDTHbRVOjCH2+7n0rspUpbOK4Qw@mail.gmail.com Whole thread Raw |
| In response to | Re: PL/pgSQL 2 (Jan Wieck <jan@wi3ck.info>) |
| Responses |
Re: PL/pgSQL 2
Re: PL/pgSQL 2 |
| List | pgsql-hackers |
On Tue, Sep 2, 2014 at 7:08 PM, Jan Wieck <jan@wi3ck.info> wrote:
When confronted by a difficult problem, solve it by reducing it to theOn 09/02/2014 06:56 PM, Andrew Dunstan wrote:I hear you and agree to some degree.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.
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.
--
question, "How would the Lone Ranger handle this?"
pgsql-hackers by date: