| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | <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 00:09:37 |
| Message-ID: | 55972441.8020001@BlueTreble.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2015-07-04 00:33:31 | More work on SortSupport for text - strcoll() and strxfrm() caching |
| Previous Message | David Rowley | 2015-07-03 23:30:57 | Re: PATCH:do not set Win32 server-side socket buffer size on windows 2012 |