Re: Anonymous code blocks vs CREATE LANGUAGE
От | Robert Haas |
---|---|
Тема | Re: Anonymous code blocks vs CREATE LANGUAGE |
Дата | |
Msg-id | 603c8f070909221050q27e1849dmdd55b47202788c66@mail.gmail.com обсуждение исходный текст |
Ответ на | Anonymous code blocks vs CREATE LANGUAGE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Anonymous code blocks vs CREATE LANGUAGE
Re: Anonymous code blocks vs CREATE LANGUAGE |
Список | 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 по дате отправления: