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.
Showing
Please register or sign in to comment