From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: generic builtin functions |
Date: | 2005-12-08 21:19:46 |
Message-ID: | 24969.1134076786@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2005-12-08 22:00:14 | Re: Improving free space usage (was: Reducing relation locking |
Previous Message | Ron Mayer | 2005-12-08 20:34:03 | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking |