2008/6/1 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/6/1 Tom Lane <[EMAIL PROTECTED]>:
>>> This argument seems entirely bogus. How are they any more constant
>>> than in the other case? The value isn't going to change for the life
>>> of the portal in eithe
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/6/1 Tom Lane <[EMAIL PROTECTED]>:
>> This argument seems entirely bogus. How are they any more constant
>> than in the other case? The value isn't going to change for the life
>> of the portal in either case.
> this is true Tom, but problem is i
2008/6/1 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/6/1 Tom Lane <[EMAIL PROTECTED]>:
>>> 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
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/6/1 Tom Lane <[EMAIL PROTECTED]>:
>> 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
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 s
"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?
hello
2008/6/1 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I found following bug - using explain in stored procedures like:
>> ...
>> produce wrong result. Real plan is correct, etc variables are
>> substituted. Bud this explain show variables.
>
> This seems to
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I found following bug - using explain in stored procedures like:
> ...
> produce wrong result. Real plan is correct, etc variables are
> substituted. Bud this explain show variables.
This seems to be correctable with a one-line patch: make SPI_cursor_o
Hello
I found following bug - using explain in stored procedures like:
CREATE OR REPLACE FUNCTION test(int)
RETURNS void AS $$
DECLARE s varchar;
BEGIN
FOR s IN EXECUTE 'EXPLAIN SELECT * FROM o WHERE a = $1+1' USING $1 LOOP
RAISE NOTICE '%', s;
END LOOP;
END; $$
LANGUAGE plpgsql;
produce
