On Tue, Sep 3, 2013 at 9:13 AM, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br
/>>Andres Freund <<a href="mailto:andres@2ndquadrant.com">andres@2ndquadrant.com</a>> writes:<br />>> On
2013-09-0308:59:53 -0500, Merlin Moncure wrote:<br /> >>> While playing around with Andres's trick, I noticed
thatit works but<br />>>> will not match against operators taking "any" although those will<br />>>>
matchwith explicit schema declaration (FWICT it goes through the<br /> >>> search_path trying to explicitly
matchint/int operator then goes<br />>>> again matches "any"). That's pretty weird:<br />><br />>>
Notsurprising. We look for the best match for an operator and<br /> >> explicitly matching types will be that. If
therewere no operator(int,<br />>> int) your anyelement variant should get called.<br />><br />> Yeah, this
hasexactly nothing to do with operator precedence.<br /> > Precedence is about which operator binds tighter in cases
like"A+B*C".<br /><br />That all makes perfect sense -- thanks guys. For posterity, Andres's trick worked and did end
upsaving me some coding after all -- in my case I have to eval() some externally generated fairly complex expressions
inSQL (via pl/pgsql EXECUTE) in the context of a much larger query. My de-parsing code ended up having bugs and it was
mucheasier to tip-toe around the search_path (via SET LOCAL) and force the modified operator.<br /><br />merlin<br />