From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | hlinnaka(at)iki(dot)fi, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Determine operator from it's function |
Date: | 2015-07-04 05:33:07 |
Message-ID: | 30143.1435987987@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Marco Atzeri | 2015-07-04 07:24:21 | Re: PostgreSQL 9.5 Alpha 1 build fail with perl 5.22 |
Previous Message | Amit Kapila | 2015-07-04 05:30:33 | Re: More logging for autovacuum |