Re: [HACKERS] Add hint for function named "is"

2016-08-13 Thread Tom Lane
Jim Nasby writes: > FWIW, I've always disliked how some types could contains spaces without > being quoted. AFAIK nothing else in the system allows that, and I don't > see why character varying and timestamp with* should get a special pass. Because the SQL standard

Re: [HACKERS] Add hint for function named "is"

2016-08-13 Thread Jim Nasby
On 8/12/16 1:40 PM, Tom Lane wrote: What this is telling us is that given input like, say, SELECT 'foo'::character varying Bison is no longer sure whether "varying" is meant as a type name modifier or a ColLabel. And indeed there is *no* principled answer to that that doesn't involve

Re: [HACKERS] Add hint for function named "is"

2016-08-12 Thread Tom Lane
Greg Stark writes: > On Fri, Aug 12, 2016 at 7:40 PM, Tom Lane wrote: >> pointing out that "SELECT 42 ISNULL" is now ambiguous. Since ISNULL >> is nonstandard, maybe dropping support for it would be feasible. > Isn't ISNULL one of the lexical tricks we used

Re: [HACKERS] Add hint for function named "is"

2016-08-12 Thread Greg Stark
On Fri, Aug 12, 2016 at 7:40 PM, Tom Lane wrote: > pointing out that "SELECT 42 ISNULL" is now ambiguous. Since ISNULL > is nonstandard, maybe dropping support for it would be feasible. Isn't ISNULL one of the lexical tricks we used to effectively give bison two token

Re: [HACKERS] Add hint for function named "is"

2016-08-12 Thread Tom Lane
I wrote: > Robert Haas writes: >> I think I experimented with this a while ago and found that even after >> removing postfix operators there was at least one other grammar >> problem that prevented us from accepting ColLabel there. I gave up >> and didn't dig further, but

Re: [HACKERS] Add hint for function named "is"

2016-08-12 Thread Tom Lane
Robert Haas writes: > Half a percent for two productions is not bad, but I think the real > win would be in removing ambiguity from the grammar. We get periodic > complaints about the fact that things like "SELECT 3 cache" don't work > because cache is an unreserved

Re: [HACKERS] Add hint for function named "is"

2016-08-12 Thread Robert Haas
On Fri, Aug 12, 2016 at 12:57 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Aug 12, 2016 at 9:40 AM, Greg Stark wrote: >>> I wonder whether it's really worth keeping postfix operators. They >>> seem to keep causing these kinds of

Re: [HACKERS] Add hint for function named "is"

2016-08-12 Thread Tom Lane
Robert Haas writes: > On Fri, Aug 12, 2016 at 9:40 AM, Greg Stark wrote: >> I wonder whether it's really worth keeping postfix operators. They >> seem to keep causing these kinds of headaches and I wonder how much >> the grammar tables would be simplified by

Re: [HACKERS] Add hint for function named "is"

2016-08-12 Thread Robert Haas
On Fri, Aug 12, 2016 at 9:40 AM, Greg Stark wrote: > On Thu, Aug 11, 2016 at 10:54 PM, Tom Lane wrote: > >> 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

Re: [HACKERS] Add hint for function named "is"

2016-08-12 Thread Tom Lane
Jim Nasby writes: > 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? No. The grammar can't assume that it's being run inside a transaction (consider parsing START

Re: [HACKERS] Add hint for function named "is"

2016-08-12 Thread Greg Stark
On Thu, Aug 11, 2016 at 10:54 PM, Tom Lane wrote: > 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 ... >

Re: [HACKERS] Add hint for function named "is"

2016-08-11 Thread Jim Nasby
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 ...

Re: [HACKERS] Add hint for function named "is"

2016-08-11 Thread Tom Lane
"David E. Wheeler" writes: > On Aug 11, 2016, at 2:11 PM, Jim Nasby wrote: >> SELECT 'x'||is(); >> ERROR: syntax error at or near "(" > Why does it need quotation marks in this case? It doesn't, if you do something like regression=# select

Re: [HACKERS] Add hint for function named "is"

2016-08-11 Thread David E. Wheeler
On Aug 11, 2016, at 2:11 PM, Jim Nasby wrote: > CREATE FUNCTION pg_temp.is() RETURNS text LANGUAGE sql AS $$SELECT > 'x'::text$$; > SELECT 'x'||is(); > ERROR: syntax error at or near "(" > LINE 1: SELECT 'x'||is(); > > I was finally able to figure out this was

[HACKERS] Add hint for function named "is"

2016-08-11 Thread Jim Nasby
CREATE FUNCTION pg_temp.is() RETURNS text LANGUAGE sql AS $$SELECT 'x'::text$$; SELECT 'x'||is(); ERROR: syntax error at or near "(" LINE 1: SELECT 'x'||is(); I was finally able to figure out this was because "is" needs to be quoted; is there a way this could be hinted? FWIW, the real-world