Re: Anonymous code blocks

Petr Jelinek <pjmodos(at)pjmodos(dot)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