Hi hackers,

If I evaluate expression typename('literal'), then type coercion is performed and the function is successfully resolved, i.e.

    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

Reply via email to