From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Anonymous code blocks vs CREATE LANGUAGE |
Date: | 2009-09-22 17:50:45 |
Message-ID: | 603c8f070909221050q27e1849dmdd55b47202788c66@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 22, 2009 at 1:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm going through the anonymous-code-blocks patch now. There are some
> things missing, notably the ability to create a language with an
> anonymous-code-block handler. The only way you can do it is to have
> a pg_pltemplate entry, which is certainly not good enough for languages
> not distributed with the core. The obvious solution is to add an
> optional clause "INLINE function_name" to CREATE LANGUAGE, paralleling
> the VALIDATOR clause. This'd require adding INLINE as a keyword.
> (I assume it could be an unreserved keyword, but haven't actually tried
> yet.) Does anyone object to that plan, or want to propose a different
> keyword?
Should we consider another generic options syntax, while we're on a
roll? In the long run, that's the best way to avoid having a zillion
keywords.
CREATE LANGUAGE name (TRUSTED, PROCEDURAL, HANDLER x, VALIDATOR y, INLINE z);
> Also, I'm pretty strongly tempted to get rid of the obsolete LANCOMPILER
> option while at it, and thereby remove that keyword. That option hasn't
> even been documented since 7.1, and didn't do anything useful for
> several versions before that. So it's pretty hard to believe anyone's
> still using it.
Seems like a no-brainer.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-09-22 17:53:22 | Re: [PATCH] Largeobject access controls |
Previous Message | Merlin Moncure | 2009-09-22 17:44:04 | Re: Anonymous code blocks |