Re: Additional SPI functions
От | James William Pye |
---|---|
Тема | Re: Additional SPI functions |
Дата | |
Msg-id | B2A429CA-1F13-4FE1-A6C4-DBC699EA8061@jwp.name обсуждение исходный текст |
Ответ на | Re: Additional SPI functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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 statementsmyself(well, the parser does it so swimmingly =). It's purpose is to allow the user to put a chunk of SQL into a single big block: sqlexec("""CREATE TEMP TABLE one ...;CREATE TEMP TABLE two ...;<init temp tables with data for use in the procedure> """) For me, that tends to read better than breaking up the calls. Well, the above may be a bad example for crying about readability, but I'm thinking of cases with a bit more SQL in em'.. [spi_prepare_statement] > This looks like it's most likely redundant with the stuff I added > recently for the plpgsql parser rewrite. If that allows me to identify the parameter type Oids of the statement, optionally supply constant parameters after identifyingthe types(so I can properly create the parameter Datums), and provides access to the resultDesc, then yes it isredundant. Personally, I'm hoping for redundant. =) > Please see if you can use that instead. I took a very short peak (wasn't really looking..) earlier today (err yesterday now) and nothing jumped out at me, but I'lltake a closer look now. Thanks =)
В списке pgsql-hackers по дате отправления: