Skip site navigation (1) Skip section navigation (2)

Re: Anonymous code blocks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Petr Jelinek <pjmodos(at)pjmodos(dot)net>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: Anonymous code blocks
Date: 2009-09-22 23:49:29
Message-ID: 7067.1253663369@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-09-22 23:52:53
Subject: pgsql: Unicode escapes in E'...' strings Author: Marko Kreen
Previous:From: Greg SmithDate: 2009-09-22 23:17:20
Subject: Re: [PATCH] pgbench: new feature allowing to launch shell commands

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group