On Thu, May 29, 2014 at 08:33:05AM -0400, Peter Eisentraut wrote:
> On 5/28/14, 7:02 PM, Andres Freund wrote:
> > That's a good idea. What i've been thinking about is to add
> > -Wno-deprecated to the bison rule in the interim. Maybe after a
> > configure test for the option. All deprecation warnin
Andres Freund writes:
> FWIW, I vote for applying something like it. It seems better to collect
> the -Wno-deprecated in one place (i.e. configure) instead of having it
> in every developer's Makefile.custom. The latter will be harder to get
> rid of.
Yeah, that's a good point.
> I'd add a comme
On 2014-05-29 08:33:05 -0400, Peter Eisentraut wrote:
> On 5/28/14, 7:02 PM, Andres Freund wrote:
> > That's a good idea. What i've been thinking about is to add
> > -Wno-deprecated to the bison rule in the interim. Maybe after a
> > configure test for the option. All deprecation warnings so far se
On 5/28/14, 7:02 PM, Andres Freund wrote:
> That's a good idea. What i've been thinking about is to add
> -Wno-deprecated to the bison rule in the interim. Maybe after a
> configure test for the option. All deprecation warnings so far seem to
> be pretty unhelpful.
Here is a patch.
diff --git a/c
On 2014-05-28 19:12:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-28 18:52:22 -0400, Tom Lane wrote:
> >> and IMO we should also lobby the Bison people to not emit the
> >> deprecation warnings yet.
>
> > That's a good idea. What i've been thinking about is to add
> > -Wno-depr
On 2014-05-28 18:52:22 -0400, Tom Lane wrote:
> I guess we have to revert this
Looks like it.
> and IMO we should also lobby the Bison people to not emit the
> deprecation warnings yet.
That's a good idea. What i've been thinking about is to add
-Wno-deprecated to the bison rule in the interim.
