Determine operator from it's function

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers