Re: Anonymous code blocks vs CREATE LANGUAGE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Anonymous code blocks vs CREATE LANGUAGE
Date
Msg-id 603c8f070909221050q27e1849dmdd55b47202788c66@mail.gmail.com
Whole thread Raw
In response to Anonymous code blocks vs CREATE LANGUAGE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Anonymous code blocks vs CREATE LANGUAGE
Re: Anonymous code blocks vs CREATE LANGUAGE
List pgsql-hackers
On Tue, Sep 22, 2009 at 1:26 PM, Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Anonymous code blocks
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Largeobject access controls