Re: execution plan and record variable in dynamic sql
От | David G Johnston |
---|---|
Тема | Re: execution plan and record variable in dynamic sql |
Дата | |
Msg-id | 1418713174152-5830851.post@n5.nabble.com обсуждение исходный текст |
Ответ на | execution plan and record variable in dynamic sql (Пушкин Сергей <pushkinsv@gmail.com>) |
Ответы |
Re: execution plan and record variable in dynamic sql
|
Список | pgsql-bugs |
=D0=9F=D1=83=D1=88=D0=BA=D0=B8=D0=BD =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 w= rote > Hello! >=20 > The following code results in error, if executed in one session: >=20 > select * from exec($$ select 1 as status $$); > select * from exec($$ select 'test' as status $$); >=20 > Version: > PostgreSQL 9.4rc1 on x86_64-unknown-linux-gnu, compiled by gcc (Debian = =20 > 4.9.2-2) 4.9.2, 64-bit > also checked on PostgreSQL 9.1.9 SQL is a strongly typed language and this is a natural consequence of dealing with dynamic queries in such an environment. The performance gains of caching outweigh the ability to make code like your example work. You may wish to share a real use case that you think requires this to not error - and explain what it is you think it should do instead. The first notice works only because any record type can be converted to tex= t regardless of the underlying fields but as soon as you want fields it matters that what you request matches the stored model. I think parameter 4 is the % in the format string...that string is cached with an integer type input and then is confused when an unknown is provided the next time around... I'm not sure how Line 8 is calculated in your example... David J. -- View this message in context: http://postgresql.nabble.com/execution-plan-a= nd-record-variable-in-dynamic-sql-tp5830846p5830851.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
В списке pgsql-bugs по дате отправления: