On 12/12/2010 10:43 AM, Tom Lane wrote:
>
>> At the moment the behaviour is triggered by a custom setting
>> (plperl.pass_binary_bytea), but this isn't really satisfactory. We could
>> turn it on permanently, but that would break a lot of legacy code. What
>> we really need is a way of marking a function with some attributes. Of
>> course, we could put it in the program text like plpgsql's
>> #variable_conflict, but that's really rather ugly. The grammar already
>> has an attribute mechanism for functions, and ISTM we just need to
>> extend that a bit to allow setting of function attributes reasonably
>> flexibly, much as we can now specify format options on EXPLAIN or we'll
>> soon be able to specify options for foreign tables.
> I do not want to go there. What you're proposing will soon turn into a
> real mess, with arbitrary language-specific junk tagged onto pg_proc
> entries. And what's worse, it'll be mixed with non-language-specific
> junk, because of the existing legacy WITH entries.
>
Arguably we should deprecate those legacy entries. One, isCachable, is
stated in the docs to be be obsolete, and has been for many releases
now. The other, isStrict, is a non-preferred way of specifying that the
function is strict.
But the real issue is that we have no way of specifying properties for a
function at creation time other than those provided for in the grammar.
We've already made a couple of fairly ugly hacks to do stuff like this
in plpgsql. Is that really the road we want to go down? Is it less messy
than providing some catalog support for language specific function
properties, where they might be visible outside the function source?
In the present case, Robert's suggestion of using "create function ...
set plperl.pass_binary_bytea = true" seems to work well enough, although
I haven't tried very hard yet to break it.
cheers
andrew