On 8/11/16 4:54 PM, Tom Lane wrote:
> which probably contributes to Jim's confusion. I think what is happening
> in the trouble case is that since IS has lower precedence than Op, the
> grammar decides it ought to resolve || as a postfix operator, and then
> it effectively has
> ('x' ||) IS ...
FWIW, is() || is() blows up in the same way.
> I'm not sure there's much we can do about this. Even if we had control of
> what Bison prints for syntax errors, which we don't really, it's hard to
> see what condition we could trigger the hint on that wouldn't result in
> false positives at least as often as something helpful. (Note that the
> grammar's behavior can't really depend on whether a function named is()
> actually exists in the catalogs.)
Is there a place in the error reporting path where we'd still have
access to the 'is' token, and have enough control to look for a relevant
function?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
