Skip site navigation (1) Skip section navigation (2)

pgsql: Revert patch to coerce 'unknown' type parameters in the backend.

From: heikki(at)postgresql(dot)org (Heikki Linnakangas)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Revert patch to coerce 'unknown' type parameters in the backend.
Date: 2010-08-19 16:54:49
Message-ID: 20100819165449.D6F117541D7@cvs.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committers
Log Message:
-----------
Revert patch to coerce 'unknown' type parameters in the backend. As Tom
pointed out, it would need a 2nd pass after the whole query is processed to
correctly check that an unknown Param is coerced to the same target type
everywhere. Adding the 2nd pass would add a lot more code, which doesn't
seem worth the risk given that there isn't much of a use case for passing
unknown Params in the first place. The code would work without that check,
but it might be confusing and the behavior would be different from the
varparams case.

Instead, just coerce all unknown params in a PL/pgSQL USING clause to text.
That's simple, and is usually what users expect.

Revert the patch in CVS HEAD and master, and backpatch the new solution to
8.4. Unlike the previous solution, this applies easily to 8.4 too.

Tags:
----
REL9_0_STABLE

Modified Files:
--------------
    pgsql/src/backend/parser:
        parse_param.c (r2.4.4.1 -> r2.4.4.2)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_param.c?r1=2.4.4.1&r2=2.4.4.2)
    pgsql/src/pl/plpgsql/src:
        pl_exec.c (r1.261.2.1 -> r1.261.2.2)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.c?r1=1.261.2.1&r2=1.261.2.2)

pgsql-committers by date

Next:From: Heikki LinnakangasDate: 2010-08-19 16:54:51
Subject: pgsql: Revert patch to coerce 'unknown' type parameters in the backend.
Previous:From: Heikki LinnakangasDate: 2010-08-19 16:54:43
Subject: pgsql: Revert patch to coerce 'unknown' type parameters in the backend.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group