2008/6/1 Tom Lane <[EMAIL PROTECTED]>: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: >> 2008/6/1 Tom Lane <[EMAIL PROTECTED]>: >>> 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
