pgsql: Mark internal_in as not strict, so that the construct - Mailing list pgsql-committers

From tgl@postgresql.org (Tom Lane)
Subject pgsql: Mark internal_in as not strict, so that the construct
Date
Msg-id 20090609195101.18C5C75331E@cvs.postgresql.org
Whole thread Raw
List pgsql-committers
Log Message:
-----------
Mark internal_in as not strict, so that the construct "null::internal"
will throw an error, rather than possibly allowing someone to synthesize
a manual call to an internal-accepting function.  As of CVS HEAD and existing
releases, all such functions are either STRICT or careful about null inputs,
so there is no current security issue here.  But it seems like a good idea
to lock this down to protect against future mistakes.

In passing, similarly lock down trigger_in, language_handler_in, opaque_in,
and shell_in.  These are not believed to present any security risk, but
there's still no good reason to allow nulls of these types to be created.
I left the polymorphic pseudotypes (anyelement etc) alone, since a null
of one of those types doesn't seem to be a problem --- the worst you can
say about it is that it doesn't have an underlying non-polymorphic type.

If we were to make this change during normal development, we'd just
automatically bump catversion for a pg_proc.h change.  But since this doesn't
create a compatibility risk and isn't believed to be fixing a live bug, it
seems better not to force a catversion bump in late beta.

Modified Files:
--------------
    pgsql/src/include/catalog:
        pg_proc.h (r1.542 -> r1.543)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h?r1=1.542&r2=1.543)

pgsql-committers by date:

Previous
From: alvherre@postgresql.org (Alvaro Herrera)
Date:
Subject: pgsql: Fix typo, per Tom
Next
From: petere@postgresql.org (Peter Eisentraut)
Date:
Subject: pgsql: Fix xmlattribute escaping XML special characters twice (bug