Skip site navigation (1) Skip section navigation (2)

Re: explain doesn't work with execute using

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: explain doesn't work with execute using
Date: 2008-06-01 16:07:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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;
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 :(

(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


>                        regards, tom lane

In response to


pgsql-hackers by date

Next:From: Ron MayerDate: 2008-06-01 16:11:27
Subject: Re: Overhauling GUCS
Previous:From: Robert HodgesDate: 2008-06-01 15:58:59
Subject: Re: Core team statement on replication in PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group