Hi hackers,
If I evaluate expression typename('literal'), then type coercion is
performed and the function is successfully resolved, i.e.
Advertising
SELECT regnamespace('"pg_catalog"');
But if I want to prepare this query, I get the error:
postgres=# prepare foo as SELECT regnamespace($1);
ERROR: function regnamespace(unknown) does not exist
LINE 1: prepare foo as SELECT regnamespace($1);
Certainly, I can explicitly specify parameter type:
prepare foo (text) as SELECT regnamespace($1);
and it will work. But it is not always possible.
Actually coerce_type function can normally handle parameters.
But func_get_detail always allows coercion only for constants:
if (sourceType == UNKNOWNOID && IsA(arg1, Const))
{
/* always treat typename('literal') as coercion */
iscoercion = true;
}
If this condition is changed to:
if (sourceType == UNKNOWNOID && (IsA(arg1, Const) ||
IsA(arg1, Param)))
then the example above will normally work.
Why do I need it? I want to implement autoprepare.
My original intention was to let parse_analyze_varparams to infer type
of parameters from the context.
But it is not always possible and sometime leads to different behavior
of query.
For example if the query:
select count(*) from test_range_gist where ir @> 10;
is replaced with
select count(*) from test_range_gist where ir @> $1;
then type of parameter will be int4range rather then int, which
corresponds to the different operator.
This is why now I infer parameter type from literal value. But in this
case I get errors in parse_analyze_varparams which is not able to
resolve some functions.
The fix in func_get_detail functions solves the problem and doesn't
cause some new issues: all regression tests are passed.
So my question is whether it is possible to use the same rule for type
coercion of parameters as for constant?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
