From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FILTER/WITHIN GROUP vs. expressions; is a HINT possible here? |
Date: | 2015-04-17 00:18:41 |
Message-ID: | 55305161.6050602@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/16/2015 04:36 PM, Tom Lane wrote:
> You could imagine teaching yyerror() to have some SQL-specific knowledge
> that it could apply by comparing the current lookahead token to the
> current parse state stack ... but neither of those things are exposed
> to it by Bison. We could probably get the lookahead token indirectly
> by inspecting the lexer's state, but it's not clear that's enough to
> do much. In this particular example, that would mean showing the exact
> same hint whenever a syntax error is reported at an OVER token; and
Yeah, and that's what we *don't* want to do. That's why I was wondering
if it was even possible to figure out the "extra syntax" case.
> I'm afraid that it'd be mighty hard to write a hint for that that
> wouldn't frequently do more harm than good. (Note in particular that
> since OVER, FILTER, and WITHIN are unreserved keywords, they might be
> used as simple column/table/function names.)
No kidding. Heck, I just spent 1/2 hour figuring out a bug which was
actually caused by the fact that a user created a view called "mode".
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2015-04-17 01:13:56 | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |
Previous Message | Andrew Dunstan | 2015-04-16 23:49:09 | Re: Supporting src/test/modules in MSVC builds |