]> granicus.if.org Git - postgresql/commit
Mark internal_in as not strict, so that the construct "null::internal"
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 9 Jun 2009 19:51:00 +0000 (19:51 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 9 Jun 2009 19:51:00 +0000 (19:51 +0000)
commite343eaafc2cc7f39235ffe10c78dd7275a9f2d04
treed7b0cd794242eb8a0ffc0e59c5e2ae815f7259a7
parente66576e58c3fb49db7729607863d66e807f3d267
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.
src/include/catalog/pg_proc.h