Re: Identifying no-op length coercions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Identifying no-op length coercions
Date
Msg-id 18282.1306177300@sss.pgh.pa.us
Whole thread Raw
In response to Re: Identifying no-op length coercions  (Noah Misch <noah@leadboat.com>)
Responses Re: Identifying no-op length coercions  (Greg Stark <gsstark@mit.edu>)
Re: Identifying no-op length coercions  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
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
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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Identifying no-op length coercions
Next
From: Robert Haas
Date:
Subject: Re: crash-safe visibility map, take five