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