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-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
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 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
When using the OSSP UUID library, cache its uuid_t state object.
The original coding in contrib/uuid-ossp created and destroyed a uuid_t
object (or, in some cases, even two of them) each time it was called.
This is not the intended usage: you're supposed to keep the uuid_t object
around so that th
When using the OSSP UUID library, cache its uuid_t state object.
The original coding in contrib/uuid-ossp created and destroyed a uuid_t
object (or, in some cases, even two of them) each time it was called.
This is not the intended usage: you're supposed to keep the uuid_t object
around so that th
When using the OSSP UUID library, cache its uuid_t state object.
The original coding in contrib/uuid-ossp created and destroyed a uuid_t
object (or, in some cases, even two of them) each time it was called.
This is not the intended usage: you're supposed to keep the uuid_t object
around so that th
When using the OSSP UUID library, cache its uuid_t state object.
The original coding in contrib/uuid-ossp created and destroyed a uuid_t
object (or, in some cases, even two of them) each time it was called.
This is not the intended usage: you're supposed to keep the uuid_t object
around so that th
When using the OSSP UUID library, cache its uuid_t state object.
The original coding in contrib/uuid-ossp created and destroyed a uuid_t
object (or, in some cases, even two of them) each time it was called.
This is not the intended usage: you're supposed to keep the uuid_t object
around so that th
When using the OSSP UUID library, cache its uuid_t state object.
The original coding in contrib/uuid-ossp created and destroyed a uuid_t
object (or, in some cases, even two of them) each time it was called.
This is not the intended usage: you're supposed to keep the uuid_t object
around so that th
Andres Freund wrote:
> On 2014-05-28 23:39:56 +0100, Simon Riggs wrote:
> > Good thought. I'll backpatch.
>
> Cool. Happy to escape my first backpatch for a little while longer :)!
Meh. Pretty sure it'll be a no-brainer for you.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
Pos
In release notes, mention the need to initialize bgw_notify_pid.
Michael Paquier
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/42be7d6923e52a8c1ceb549c0931ac43a4954b86
Modified Files
--
doc/src/sgml/release-9.4.sgml |9 +
1 file changed, 9 i
12 matches
Mail list logo
