Re: Anonymous code blocks

Petr Jelinek <pjmodos@pjmodos.net> writes:
>  [ anonymous code blocks patch ]

I committed this after some editorialization.  Aside from adding missing
CREATE LANGUAGE and pg_dump support, I didn't like the API for inline
handler functions.  Passing just a C string doesn't allow for any future
expansibility (eg adding parameters), and it represents a security hole
because anyone could call the function, thereby bypassing the privilege
checks.  I changed things so that the inline handlers are declared as
taking type INTERNAL, which will prevent them from being called manually
from SQL.  Also, I made the actual argument be a new Node struct type.
(I first thought of passing the DO statement's parse node as-is, but
that would require every handler to re-implement the deconstruction of
the DefElem list.  So a separate struct type seemed like a better idea.)
With this, we can add parameters or what have you without any changes
in the catalog-level representation of the languages or inline handlers.
I did some renaming too --- we generally expect that parsenodes
associated with statement types are named after the statement, for
instance.

The do.sgml file was missing from both your submissions, so I cooked
up a very quick-and-dirty reference page.  It could stand to be fleshed
out a bit, probably.  If there's useful material in your original,
please submit a followon patch to add it.

> Actually I think we might not need that function memory context for 
> anonymous code blocks at all since we don't cache compiled functions. 
> But I am not sure so I basically copied it from standard function 
> compiler to be on safe side. I am sure commiter will comment on this :)

Yeah, I got rid of that: it created a session-lifespan memory leak for
every execution of a DO command.  There's no reason not to just do it
in the current memory context.
        regards, tom lane