On 7/4/15 12:33 AM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> On 7/3/15 2:33 AM, Heikki Linnakangas wrote:
>>> On 07/03/2015 01:20 AM, Jim Nasby wrote:
>>>> Is there a way to determine the operator that resulted in
>>>> calling the operator function? I thought
>>>> fcinfo->flinfo->fn_expr might get set to the OpExpr, but seems
>>>> it can be a FuncExpr even when called via an operator...
>
>>> Don't think there is. Why do you need to know?
>
>> I'd like to support arbitrary operators in variant.
>
> Why would you expect there to be multiple operators pointing at the
> same function? If there were multiple operators pointing at the same
> function, why would you need to distinguish them? ISTM that such a
> situation would necessarily mean that there was no distinction worthy
> of notice.
Because frequently there *almost* is no distinction. Witness the large
number of *_cmp functions and the 6 wrappers that normally accompany them.
> (The particular situation you are bitching about comes from the fact
> that eval_const_expressions's simplify_functions code deliberately
> ignores any distinction between operators and functions. But for its
> purposes, that is *correct*, and I will strongly resist any claim
> that it isn't. If you are unhappy then you defined your operators
> wrongly.)
I'm not sure how you got 'bitching' out of what I said:
> I did initial testing and it looked like I was getting an OpExpr in
> fn_expr, but I think that's because I was using a real table to test
> with. When I do something like 'a' < 'b' it looks like the operator
> gets written out of the plan. If that's indeed what's happening is
> there a hook I could use to change that behavior?
All I need is a way to know what the original operator was. In this case
an OpExpr would be easiest but presumably it wouldn't be difficult to
turn a Name into an OpExpr.
FWIW, if we had this then by my count we could get rid of ~130 wrapper
functions:
decibel@decina:[10:38]~/pgsql/HEAD/src/backend (master $%=)$git grep
_cmp|grep PG_RETURN_BOOL|wc -l 130
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com