An example that Elein put up yesterday: http://archives.postgresql.org/pgsql-general/2005-04/msg01384.php caused me to realize that type output functions that depend on additional arguments to determine what they are dealing with are fundamentally security holes. It is trivial to crash 8.0's record_out by lying to it about the rowtype of its first argument.
I have fixed that in CVS tip (and I suppose we had better think about a security update) ... but what I am now contemplating is taking steps of various levels of draconianness to make sure we don't get burnt this way again. At a minimum I am going to change the type_sanity regression test to complain about built-in output functions that have multiple arguments. I am also fairly strongly tempted to modify CREATE TYPE so that it doesn't allow user-defined types to have multi-argument output functions, either. I doubt there is anyone out there trying to do that, because the extra arguments that are passed don't seem useful for any non-builtin types. But I thought I should throw it out for discussion --- has anyone got a problem with such a change? BTW, the comparable arguments for input functions are not dangerous, and in fact are necessary. The reason they are not dangerous is that every datatype input converter applies sufficient sanity checks to input text strings to not accept invalid input. We have an issue on the output side because internal representations are generally taken on faith to be valid (and would be hard to validate even if we tried). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings