On Tue, May 21, 2019 at 03:06:43PM -0400, Tom Lane wrote:
> * Speed of the generated parser could be better. I suspect this has
> a lot to do with the fact that our grammar is huge, and so are the
> tables, and that causes lots of cache misses. Maybe this could be
> addressed by trying to make th
On 2019-May-28, Andrew Gierth wrote:
> The main cases I know of are:
>
> 1. RANGE UNBOUNDED PRECEDING - this one is actually a defect in the
> standard SQL grammar, since UNBOUNDED is a non-reserved keyword and so
> it can also appear as a legal , and the construct
> RANGE PRECEDING allows to
>
> "Akim" == Akim Demaille writes:
>> Yeah, we've definitely found that resolving shift/reduce conflicts
>> via precedence declarations has more potential for surprising
>> side-effects than one would think.
Akim> That's why in recent versions of Bison we also provide a means to
Akim> pu
Hey Tom,
> Le 22 mai 2019 à 23:25, Tom Lane a écrit :
>
> Akim Demaille writes:
>> Honestly, I seriously doubt that you have contributors that don't
>> have MacPorts or Brew installed, and both are pretty up to date on
>> Bison.
>
> Hm, well, I'm a counterexample ;-).
Wow :) I have even more
hi Tom!
> Le 23 mai 2019 à 00:29, Tom Lane a écrit :
>
> Andrew Dunstan writes:
>> On 5/21/19 11:49 AM, Akim Demaille wrote:
>>> Usually users of Bison build tarballs with the generated parsers
>>> in them, and ship/test from that.
>
>> The buildfarm client does not build from tarballs, it bui
Tom,
> Le 23 mai 2019 à 06:00, Tom Lane a écrit :
>
> Robert Haas writes:
>> Another thing is that it would be nice to have a better way of
>> resolving conflicts than attaching precedence declarations. Some
>> problems can't be solved that way at all, and others can only be
>> solved that way
> Le 22 mai 2019 à 23:44, Daniel Gustafsson a écrit :
>
>> On 22 May 2019, at 23:25, Tom Lane wrote:
>>
>> Akim Demaille writes:
>>> Honestly, I seriously doubt that you have contributors that don't
>>> have MacPorts or Brew installed, and both are pretty up to date on
>>> Bison.
>>
>> Hm,
Hi,
On 2019-05-22 17:25:31 -0400, Tom Lane wrote:
> The easiest method is to fire up some client code that repeatedly
> does whatever you want to test, and then look at perf or oprofile
> or local equivalent to see where the time is going in the backend
> process.
>
> For the particular case of s
On Thu, May 23, 2019 at 12:00 AM Tom Lane wrote:
> > One possible
> > idea is a way to mark a rule %weak, meaning that it should only be
> > used if no non-%weak rule could apply. I'm not sure if that would
> > really be the best way, but it's one idea. A more general version
> > would be some k
Hi Tom,
> Le 21 mai 2019 à 21:06, Tom Lane a écrit :
>
> Akim Demaille writes:
>>> Le 20 mai 2019 à 15:54, Tom Lane a écrit :
>>> 2013? Certainly not. We have a lot of buildfarm critters running
>>> older platforms than that.
>
>> This I fully understand. However, Bison is a source generat
Robert Haas writes:
> Another thing is that it would be nice to have a better way of
> resolving conflicts than attaching precedence declarations. Some
> problems can't be solved that way at all, and others can only be
> solved that way at the risk of unforeseen side effects.
Yeah, we've definit
On Tue, May 21, 2019 at 3:07 PM Tom Lane wrote:
> Other PG hackers might have a different laundry list, but that's mine.
Good list.
Another thing is that it would be nice to have a better way of
resolving conflicts than attaching precedence declarations. Some
problems can't be solved that way a
Andrew Dunstan writes:
> On 5/21/19 11:49 AM, Akim Demaille wrote:
>> Usually users of Bison build tarballs with the generated parsers
>> in them, and ship/test from that.
> The buildfarm client does not build from tarballs, it builds from git,
> meaning it has to run bison. Thus Tom's objection
On 5/21/19 11:49 AM, Akim Demaille wrote:
> Hi Tom!
>
>> Le 20 mai 2019 à 15:54, Tom Lane a écrit :
>>
>> Akim Demaille writes:
>>> It is for the same reasons that I would recommend not using associativity
>>> directives (%left, %right, %nonassoc) where associativity plays no role:
>>> %prece
> On 22 May 2019, at 23:25, Tom Lane wrote:
>
> Akim Demaille writes:
>> Honestly, I seriously doubt that you have contributors that don't
>> have MacPorts or Brew installed, and both are pretty up to date on
>> Bison.
>
> Hm, well, I'm a counterexample ;-)
And one more. While I do have brew
Akim Demaille writes:
> Honestly, I seriously doubt that you have contributors that don't
> have MacPorts or Brew installed, and both are pretty up to date on
> Bison.
Hm, well, I'm a counterexample ;-). Right now you can develop PG
on a Mac just fine without any additional stuff, excepting mayb
Akim Demaille writes:
>> Le 20 mai 2019 à 15:54, Tom Lane a écrit :
>> 2013? Certainly not. We have a lot of buildfarm critters running
>> older platforms than that.
> This I fully understand. However, Bison is a source generator,
> and it's quite customary to use modern tools on the maintain
Hi Tom!
> Le 20 mai 2019 à 15:54, Tom Lane a écrit :
>
> Akim Demaille writes:
>> It is for the same reasons that I would recommend not using associativity
>> directives (%left, %right, %nonassoc) where associativity plays no role:
>> %precedence is made for this. But it was introduced in Bi
Akim Demaille writes:
> It is for the same reasons that I would recommend not using associativity
> directives (%left, %right, %nonassoc) where associativity plays no role:
> %precedence is made for this. But it was introduced in Bison 2.7.1
> (2013-04-15), and I don't know if requiring it is
Hi Tom,
> Le 19 mai 2019 à 20:27, Tom Lane a écrit :
>
> Akim Demaille writes:
>> In the following two proposed patches, I remove directives that are
>> completely useless.
>
> I'm far from convinced that the proposed changes in gram.y are a good
> idea. Both [] and . (field selection) *are*
Akim Demaille writes:
> In the following two proposed patches, I remove directives that are
> completely useless.
I'm far from convinced that the proposed changes in gram.y are a good
idea. Both [] and . (field selection) *are* left-associative in a
meaningful sense, so even if this change happe
Hi all,
Many of the grammars could be clarified. For instance there's a number of
useless associativity and/or precedence declarations. Maybe the point is to
leave some form of a documentation, but actually, since it's not used at all by
the tool, that documentation is not checked.
In the fo
22 matches
Mail list logo
