Re: generic builtin functions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: generic builtin functions
Дата
Msg-id 24969.1134076786@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: generic builtin functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: generic builtin functions  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Ron Mayer
Дата:
Сообщение: Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Improving free space usage (was: Reducing relation locking