Skip site navigation (1) Skip section navigation (2)

Re: Window Functions: v07 APIs and buffering strateties

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>
Cc: "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Window Functions: v07 APIs and buffering strateties
Date: 2008-10-28 12:55:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> writes:
> OK, I'll try to remove it. I'm not used to bison so my first task is
> to find where the conflict is...

Use bison -v to get details of where the conflict is.  I find that
the most common way to fix things is to postpone where the parser
has to make a decision, which usually ends up meaning a slightly
more verbose set of productions --- for instance instead of

	foo: bar opt_baz

	opt_baz: baz | /*EMPTY*/

you might have to do

	foo: bar baz | bar

(which is actually shorter in this pseudo-example, but wouldn't be
if bar were complicated or foo had a lot of alternatives already).
The reason this can fix it is that the parser doesn't have to commit
to which case applies until after it's read the tokens for baz.
In the first form, it has to decide whether baz is there or not
without looking any further ahead than the first token of baz.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2008-10-28 12:57:13
Subject: Re: Visibility map, partial vacuums
Previous:From: Hannu KrosingDate: 2008-10-28 12:45:48
Subject: Re: VACUUMs and WAL

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group