=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.
