Thread: Anonymous code blocks vs CREATE LANGUAGE
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?
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.
regards, tom lane
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
On Tue, Sep 22, 2009 at 01:50:45PM -0400, Robert Haas wrote: > 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); I understand that some PLs are OO, functional, etc., but for our purposes, isn't PROCEDURAL just noise? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Tom Lane 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? > works for me. After this is committed I will work to provide such an animal for plperl - we already have code that does something similar for the utf8 bug, so it should be fairly simple. > 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. > > > +1. cheers andrew
Robert Haas <robertmhaas@gmail.com> writes:
> 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.
If there were any near-term prospect of more options for languages,
I might agree ... but there isn't, so I'm having a hard time getting
excited about this.
regards, tom lane