Re: [HACKERS] Additional SPI functions

2009-12-27 Thread James William Pye
On Dec 20, 2009, at 12:03 AM, Tom Lane wrote: This looks like it's most likely redundant with the stuff I added recently for the plpgsql parser rewrite. Please see if you can use that instead. The parser param hooks will definitely work. As for getting the result TupleDesc prior to

Re: [HACKERS] Additional SPI functions

2009-12-20 Thread James William Pye
On Dec 20, 2009, at 12:03 AM, Tom Lane wrote: Why not code a loop around one of the existing SPI execution functions? *shrug* seemed nicer to push it on the parser than to force the user to split up the statements/calls. Or split up the statements myself(well, the parser does it so swimmingly

[HACKERS] Additional SPI functions

2009-12-19 Thread James William Pye
In the event that my plpython3 patch does not make it, it seems prudent to try and get a *much* smaller patch in to allow the PL to easily exist out of core. I added a couple SPI functions in order to support the database access functionality in plpython3u. Also, a getelevel() function for

Re: [HACKERS] Additional SPI functions

2009-12-19 Thread Tom Lane
James William Pye li...@jwp.name writes: extern int SPI_execute_statements(const char *src); Execute multiple statements. Intended, primarily, for executing one or more DDL or DML statements. In contrast with the other execution functions, the RPT loop plans and executes the statement