Thread: Determine operator from it's function
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... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com
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? - Heikki
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. 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? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com
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.
(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.)
regards, tom lane
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