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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers