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.
nm
