Re: PL/pgSQL EXECUTE '..' USING with unknown

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL EXECUTE '..' USING with unknown
Date: 2010-08-17 11:01:42
Message-ID: AANLkTinCpCwMXhe8Pk5Mqx=UDSjJuc0pMus9=Nfo19Xj@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/8/16 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> =?ISO-8859-1?Q?C=E9dric_Villemain?= <cedric(dot)villemain(dot)debian(at)gmail(dot)com> writes:
>> Yes, and you point out another thing. EXECUTE is a way to bypass the
>> named prepare statement, to be sure query is replanned each time.
>> Unfortunely the current implementation of EXECUTE USING is not working
>> this way.
>
> Uh ... what do you base that statement on?

About the planning behavior ?
With USING, I get a seqscan (cost and long), without USING I have an
indexscan(short and costless).

And the pg_stat* views confirm that the index is not used.
I think that the relevant code is in exec_dynquery_with_params(...).
The SPI_cursor_open_with_args receive a complete string, or a string +
params.

My use case is very simple:
EXECUTE 'SELECT status FROM ' || l_partname::regclass
|| ' WHERE uid = ' || quote_literal(p_uid)
INTO r.flag;

vs

EXECUTE 'SELECT status FROM ' || l_partname::regclass
|| ' WHERE uid = $1'
USING p_uid
INTO r.flag;

(here it is not bad, but I was very happy to be able to do a safe uid
= ANY ($1), with p_uid an array in another context.)

>
>                        regards, tom lane
>

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2010-08-17 11:04:48 Re: Git migration timeline
Previous Message Magnus Hagander 2010-08-17 09:50:20 Re: Git migration timeline