Re: function attributes

Andrew Dunstan <andrew@dunslane.net> writes:
> 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.

>> I do not want to go there.

> 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?

There might be an argument in the abstract for that, but I can't see
expending the work until we have a more pressing concrete requirement
than this one.  I don't believe that defining this particular behavior
as a function property is a good long-term solution, because it seems
practically certain that everybody will want to migrate to the new
behavior.  A GUC works well for that, because you can flip over the
default once you reach the point of having converted or marked all your
functions.  A function property doesn't work at all, unless it's just a
means of locally overriding the GUC ... and the SET clause exists for
that already.

I could be talked into function properties given a few examples of
properties that could be expected to remain in use for a long time
(like volatile/immutable for instance).  But this example is no sale.
        regards, tom lane