Martijn van Oosterhout writes:
> However, I don't know it matters. You only need to cost the plan if
> there are alternate paths and given the plan structure is strongly
> constrained, I'm not sure how much it matters.
It does, since the whole thing could be a subquery, in which case there
could
On Mon, Jan 29, 2007 at 01:38:02PM +, Gregory Stark wrote:
> Instead I suggest we create one type of reentrant node, which memoizes its
> output. It would be a kind of on-demand Materialize. It would be paired with a
> second node type which would be the only type of node which can invoke it.
>
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Having fixed that everything works fine with SET and WITH being reserved
>> keywords. You didn't mean to say I should be able to leave WITH unreserved
>> did
>> you?
>
> I think we'd decided that was a lost caus
Gregory Stark <[EMAIL PROTECTED]> writes:
> Having fixed that everything works fine with SET and WITH being reserved
> keywords. You didn't mean to say I should be able to leave WITH unreserved did
> you?
I think we'd decided that was a lost cause, unless you see a way?
> Of course that was the e
"Tom Lane" <[EMAIL PROTECTED]> writes:
> ::=
> SEARCH SET
>
> and so CYCLE would come *after* "SET " not before it.
Ah, thanks, I had glossed right over the "SET " bit. The SET
that I had was the "SET " which remains after the CYCLE keyword.
> It looks to me like we'd have to promote S
Martijn van Oosterhout writes:
> Er, CYCLE isn't a binary operator, and users can't make binary
> operators that are words, so I'm not sure of the problem here.
Well, the problem typically is not being able to tell whether an
operator is supposed to be infix or postfix; hence keywords that can
te
Ok, looking at your example:
WITH RECURSIVE foo (a,b) AS (subq) SEARCH BREADTH FIRST BY a,b , c(x,z),d(y,z)
AS (subq) SELECT ...
What you're trying to say is that the c is a ,
not a . But the parser will see that as soon as it hits
the open parenthesis, since a is always just a column
name.
Al
On Fri, Jan 26, 2007 at 05:10:01PM +, Gregory Stark wrote:
> However to fully support the DB2/ANSI syntax we would definitely have an
> ambiguity and I think we would have to make "CYCLE" a fully reserved word
> which seems like a much bigger concession than "WITH". Observe the following
> case
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Can you post the rules you have so far that you're playing around with? (Also
> maybe the rules from the standard - I don't have a copy handy).
This is the best compromise I've come up with so far. It makes CYCLE a
reserved word and requires a CYCLE
Gregory Stark wrote:
Woah, I just realized it's much worse than that. I think the syntax in the
ANSI is not parsable in LALR(1) at all. Note the following:
WITH RECURSIVE foo (a,b) AS (subq) SEARCH BREADTH FIRST BY a,b,c(x,z),d(y,z) AS
(subq) SELECT ...
To determine whether "c" is the name of
Woah, I just realized it's much worse than that. I think the syntax in the
ANSI is not parsable in LALR(1) at all. Note the following:
WITH RECURSIVE foo (a,b) AS (subq) SEARCH BREADTH FIRST BY a,b,c(x,z),d(y,z) AS
(subq) SELECT ...
To determine whether "c" is the name of a new it has to
scan
Hm, I had hoped that the DB2/ANSI syntax would only require making "WITH" a
fully reserved word, and not the other tokens it uses. Certainly for
non-recursive queries that's the case as the only other token it uses is "AS"
which is already a fully reserved word.
However to fully support the DB2/A
12 matches
Mail list logo
