Re: generic builtin functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: generic builtin functions
Date
Msg-id 24969.1134076786@sss.pgh.pa.us
Whole thread Raw
In response to Re: generic builtin functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: generic builtin functions  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Still thinking a bit more about this ... how about we have output 
> functions take an optional second argument, which is the type oid?

No.  We just undid that for good and sufficient security reasons.
If an output function depends on anything more than the contents of
the object it's handed, it's vulnerable to being lied to.
http://archives.postgresql.org/pgsql-hackers/2005-04/msg00998.php

I realize that being told the wrong type ID might be less than
catastrophic for enum_out, but I'm going to fiercely resist putting back
any extra arguments for output functions.  The temptation to use them
unsafely is just too strong --- we've learned that the hard way more
than once already, and I don't want to repeat the same mistake yet again.

> Input funcs get a typioparam and typmod argument in addition to the
> data value,

Entirely different situation because the only thing an input function
assumes is that it's been handed some text ... which it can validate.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Ron Mayer
Date:
Subject: Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking
Next
From: Hannu Krosing
Date:
Subject: Re: Improving free space usage (was: Reducing relation locking