From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add hint for function named "is" |
Date: | 2016-08-12 03:30:36 |
Message-ID: | 535800a3-d8e9-05e0-9f62-7cc59eda6b19@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-08-12 07:49:16 | [PATCH] COPY vs \copy HINT |
Previous Message | Jim Nasby | 2016-08-12 03:18:35 | Re: new autovacuum criterion for visible pages |