Re: explain doesn't work with execute using

2008/6/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2008/6/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> This seems to be correctable with a one-line patch: make SPI_cursor_open
>>> set the CONST flag on parameters it puts into the portal (attached).
>>> I'm not entirely sure if it's a good idea or not --- comments?
>
>> We can do less invasive patch - it's much more ugly, but don't change
>> any other behave. I am afraid, so one-line patch can change behave of
>> explain statements in some cases where using variables is correct.
>
> If you can name a case where that is correct, then I'll worry about
> this, but offhand I don't see one.

this case - there variables are correct

postgres=# create or replace function foo(_a integer) returns void as
$$declare s varchar; begin for s in explain select * from o where a =
_a loop raise notice '%', s; end loop; end; $$ language plpgsql;
CREATE FUNCTION
Time: 43,138 ms
postgres=# select foo(20);
NOTICE: Index Scan using o_pkey on o (cost=0.00..8.27 rows=1 width=4)
NOTICE: Index Cond: (a = 20) -- wrong :(
foo
-----

(1 row)

>
> What do you think a "less invasive" patch would be, anyway? I don't
> buy that, say, having SPI_cursor_open_with_args set the flag but
> SPI_cursor_open not do so is any safer. There is no difference between
> the two as to what might get executed, so if there's a problem then
> both would be at risk.

SPI_cursor_open_with_args is new function, it's used only in FOR
EXECUTE statement - and in this context variables are really
constants.

Pavel

>
> regards, tom lane
>