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