| 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-28 07:05:38 |
| Message-ID: | 864CA37B-4307-4FD4-B151-4ED56813E272@jwp.name |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 execution, I can include spi_priv.h and look at the CPS list directly. Something more crayola would be preferable, but I don't think "SPI_prepare_statement" is that something; although, it did make for a fine stopgap. (Well, "fine", saving that my proposed SPI_prepare_statement appeared to be broken wrt plan revalidation and bound parameters.. ew)
So, after looking into the parser hooks, CachedPlanSource, and SPI more, I ended up taking a slightly different route. I expect it to work with a couple prior versions of PG as well, so there is some added value over a new SPI function or exclusively using param hooks. And, now, thinking of compatibility with past versions of PG, I'll find a different route for "SPI_execute_statements" as well.
Thanks.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-12-28 07:11:23 | Re: Removing pg_migrator limitations |
| Previous Message | Takahiro Itagaki | 2009-12-28 03:38:59 | Verifying variable names in pgbench |