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 says so. If we were going to
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 g
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 to effectively give
> bison two token
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 lookahead?
--
greg
--
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 maybe we should.
> Yes,
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 keyword, and postfix operators
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 headaches and I wonder how much
>>> the grammar tables woul
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 removing them.
> I've wondered the sa
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 postfix operator, and then
>> it effective
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 TRANSACTION, or ROLLBACK a
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 ...
> which leaves noplace to
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 ...
"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 is();
ERROR: function is() does not exist
LINE 1: se
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 because "is" needs to be quoted;
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
15 matches
Mail list logo
