Petr Jelinek <pjmo...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
