Re: generic builtin functions

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

In response to

Responses

Browse pgsql-hackers by date

  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