> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> 2008/6/1 Tom Lane <tgl@sss.pgh.pa.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
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment