Re: PL/pgSQL EXECUTE '..' USING with unknown
От | Cédric Villemain |
---|---|
Тема | Re: PL/pgSQL EXECUTE '..' USING with unknown |
Дата | |
Msg-id | AANLkTinCpCwMXhe8Pk5Mqx=UDSjJuc0pMus9=Nfo19Xj@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PL/pgSQL EXECUTE '..' USING with unknown (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PL/pgSQL EXECUTE '..' USING with unknown
|
Список | pgsql-hackers |
2010/8/16 Tom Lane <tgl@sss.pgh.pa.us>: > Cédric Villemain <cedric.villemain.debian@gmail.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
В списке pgsql-hackers по дате отправления: