On May 24, 2011, at 12:15 AM, Noah Misch wrote:
> On Mon, May 23, 2011 at 03:01:40PM -0400, Tom Lane wrote:
>> Noah Misch <noah@leadboat.com> writes:
>>> Good deal. Given that conclusion, the other policy decision I anticipate
>>> affecting this particular patch is the choice of syntax. Presumably, it will be
>>> a new common_func_opt_item. When I last looked at the keywords list and tried
>>> to come up with something, these were the best I could do:
>>
>>> CREATE FUNCTION ... PARSER MAPPING helperfunc(args)
>>> CREATE FUNCTION ... PLANS CONVERSION helperfunc(args)
>>
>> We could go with your previous idea of not bothering to expose this in
>> the SQL syntax. Given that the helper function is going to have a
>> signature along the lines of "(internal, internal) -> internal", it's
>> going to be difficult for anyone to use it for non-builtin functions
>> anyhow.
>>
>> But if you really don't like that, what about
>
> That would be just fine with me. We can always expose it later.
>
>>
>> TRANSFORM helperfunctionname
>>
>> Although TRANSFORM isn't currently a keyword for us, it is a
>> non-reserved keyword in SQL:2008, and it seems possible that we might
>> someday think about implementing the associated features.
>
> I was thinking of that word too, along the lines of "PLAN TRANSFORM FUNCTION
> helperfunctionname". Then again, that wrongly sounds somewhat like it's
> transforming planner nodes. Perhaps plain TRANSFORM or TRANSFORM FUNCTION would
> be the way to go.
Looks like this thread has silently died out. Is there an agreement on the
syntax and implementation part? We (CMD) have a customer, who is interested in
pushing this through, so, if we have a patch, I'd be happy to assist in
reviewing it.
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
