Re: generic builtin functions

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)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.
>
>

OK, If you resist fiercely I'm sure it won't happen, so I'll put away
the asbestos underpants ;-)

I see in that discussion you say:

>Every rowtype Datum will carry its own concrete type.
>

Are we storing that on disk in every composite object? If not, where do
we get it from before calling the output function?

cheers

andrew

> regards, tom lane
>
>
>