Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
