Re: Add hint for function named "is"

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

In response to

Responses

Browse pgsql-hackers by date

  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