> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> 2008/6/1 Tom Lane <tgl@sss.pgh.pa.us>:
>>> 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.
>
> 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 in EXPLAIN. I thing, so my and your
solution are little bit incorect. We solve result, not reason. We have
problem, bacause plan doesn't carry parameter's flags, and with
EXPLAIN planner is called two times with different param's flags.
>
> ISTM you're expecting EXPLAIN to behave in some magic way that has
> got little to do with "correctness".
>
It is first time when I do some with EXPLAIN and I don't understad
well, but I would correct EXPLAIN output. When original plan use
variables I would to see variables in plan and when plan use constant
I would to see constant.
> 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