From: | James William Pye <lists(at)jwp(dot)name> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Additional SPI functions |
Date: | 2009-12-20 08:34:44 |
Message-ID: | B2A429CA-1F13-4FE1-A6C4-DBC699EA8061@jwp.name |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 statements myself(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 identifying the types(so I can properly create the parameter Datums), and provides access to the resultDesc, then yes it is redundant. 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'll take a closer look now.
Thanks =)
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-12-20 08:36:54 | alpha3 bundled -- please verify |
Previous Message | Tom Lane | 2009-12-20 07:03:14 | Re: Additional SPI functions |