| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: function attributes |
| Date: | 2010-12-12 01:58:28 |
| Message-ID: | 4D042C44.1090700@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/11/2010 08:01 PM, David E. Wheeler 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 table
> What does the existing attribute grammar for functions look like? An example perhaps?
>
>
create function foo(....) ..... with ( /attribute/ [, ...] )
Currently allowed attributes are isStrict and isCachable. The mechanism
is effectively obsolete right now, but we could use it for what I have
in mind quite nicely.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian Pflug | 2010-12-12 02:02:11 | Re: proposal: auxiliary functions for record type |
| Previous Message | Robert Haas | 2010-12-12 01:56:40 | Re: create tablespace fails silently, or succeeds improperly |