Andrew Dunstan <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
