The SE-PostgreSQL patches are updated as follows:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.5devel-r2163.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-02-core-8.5devel-r2163.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-03-gram-8.5devel-r2163.patch
[4/5] htt
On Fri, Jul 10, 2009 at 2:23 AM, Robert Haas wrote:
>> We have a wildcard cert for the domain. I'm going on vacation at the
>> weekend, and have to wrap up a bunch of stuff at work tomorrow, but if
>> you talk nicely to Stefan...
>
> Stefan, you are mighty and have powerful administration skills.
Robert Haas wrote:
On Jul 9, 2009, at 5:53 PM, Dave Page wrote:
On Thu, Jul 9, 2009 at 11:31 PM, Robert Haas
wrote:
On Jul 9, 2009, at 5:07 PM, Peter Eisentraut wrote:
On Thursday 09 July 2009 19:06:35 Brendan Jurd wrote:
Your login details for the app == your community login == your wik
On Jul 9, 2009, at 12:35 PM, Brendan Jurd wrote:
We don't AFAIK collect data about these events. However, we could
have certain actions trigger the creation of an automated comment
(e.g., "Status changed to Committed by petere") and let the
aforementioned comment view suffice for a "history".
On Wed, Jul 8, 2009 at 4:57 PM, Tom Lane wrote:
> Well, the reason I'm not voting for #3 is that it looks like a lot of
> work to implement something that would basically be a planner hint,
> which I'm generally against; furthermore, it's a hint that there's been
> no demand for. (We're not even c
2009/4/26 Brendan Jurd :
> I've done some work updating Pavel's sci notation patch for to_char().
That patch again, now with a couple of minor tweaks to make it apply
cleanly against the current HEAD.
Cheers,
BJ
_3.diff.bz2
Description: BZip2 compressed data
--
Sent via pgsql-hackers mail
http://www.sigaev.ru/misc/polygon-0.2.gz
Patch fixes wrong algorithms of contains and overlap operations over polygons.
Regression tests contain an examples of such polygons.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Stefan Kaltenbrunner wrote:
Robert Haas wrote:
On Jul 9, 2009, at 5:53 PM, Dave Page wrote:
On Thu, Jul 9, 2009 at 11:31 PM, Robert Haas
wrote:
On Jul 9, 2009, at 5:07 PM, Peter Eisentraut wrote:
On Thursday 09 July 2009 19:06:35 Brendan Jurd wrote:
Your login details for the app == you
Hi,
Le 10 juil. 09 à 17:22, Robert Haas a écrit :
I took a look at this and it seems that #3 can be implemented with
essentially no additional code (the handful of lines I added where
more than balanced out by some simplifications in ruleutils.c). Of
course you still don't have to like it. :-)
Robert Haas writes:
> I took a look at this and it seems that #3 can be implemented with
> essentially no additional code (the handful of lines I added where
> more than balanced out by some simplifications in ruleutils.c). Of
> course you still don't have to like it. :-)
You're right, I don't.
On Jul 10, 2009, at 11:48 AM, Dimitri Fontaine media.com> wrote:
Hi,
Le 10 juil. 09 à 17:22, Robert Haas a écrit :
I took a look at this and it seems that #3 can be implemented with
essentially no additional code (the handful of lines I added where
more than balanced out by some simplification
On Sun, Jan 25, 2009 at 6:57 PM, Mark Kirkwood wrote:
>
> So here is my initial attempt at this, at this point merely to spark
> discussion (attached patch)
>
this patch doesn't apply cleanly to head... can you update it, please?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQ
Robert Haas wrote:
> At any rate the particular choice of keyword seems rather
> insignificant; I picked it because it was already a keyword and
> seemed vaguely appropriate, but it could easily be changed.
Actually, if we were going to add fine-grained optimizer hints for
this (which I'm n
"Kevin Grittner" writes:
> Actually, if we were going to add fine-grained optimizer hints for
> this (which I'm not at all convinced is a good idea), I'd be tempted
> to go with what I saw a few years ago in SAP-DB (later rebranded as
> MySQL Max-DB): treat parentheses around JOIN operations as op
Tom Lane wrote:
> "Kevin Grittner" writes:
>> treat parentheses around JOIN operations as optimizer hints.
>
> That's a *truly* horrid idea, as sometimes you need them simply to
> get the precedence correct.
You do, but it's been pretty rare in my experience, and we're
considering alternative
Am I the only one having problems building 8.1 from git? (Am I the only one
building 8.1 from git?) In a clean repository, I've checked out REL8_1_STABLE,
configured with only one argument, to set --prefix, and make gives me this:
make[4]: Entering directory
`/home/josh/devel/pgsrc/pg81/src/backen
On Jul 10, 2009, at 12:06 PM, Tom Lane wrote:
Robert Haas writes:
I took a look at this and it seems that #3 can be implemented with
essentially no additional code (the handful of lines I added where
more than balanced out by some simplifications in ruleutils.c). Of
course you still don't ha
On Fri, Jul 10, 2009 at 10:22 AM, Robert Haas wrote:
> I took a look at this and it seems that #3 can be implemented with
> essentially no additional code (the handful of lines I added where
> more than balanced out by some simplifications in ruleutils.c). Of
> course you still don't have to like
"Kevin Grittner" writes:
> You do, but it's been pretty rare in my experience, and we're
> considering alternatives which give a lot less flexibility that this.
I dunno about "considering". We've already wasted vastly more time on
this than it's worth. AFAIR there has never been one single user
>> I think we might be better off just
leaving the closed commitfests up on the wiki, and putting a notice on
the app saying "commitfests prior to July 2009 can be found at
wiki.postgresql.org".
+1. That's why we're switching technogies at the beginning of a dev cycle.
--
Josh Berkus
Postgr
On Jul 10, 2009, at 11:03 AM, Joshua Tolley wrote:
Am I the only one having problems building 8.1 from git? (Am I the
only one
building 8.1 from git?) In a clean repository, I've checked out
REL8_1_STABLE,
configured with only one argument, to set --prefix, and make gives
me this:
While n
Tom Lane wrote:
> "Kevin Grittner" writes:
>> You do, but it's been pretty rare in my experience, and we're
>> considering alternatives which give a lot less flexibility that this.
>
> I dunno about "considering". We've already wasted vastly more time on
> this than it's worth. AFAIR there has
All,
I'd suggest that we publish an official policy, with the following dates
for "EOL":
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
"After the above dates, the PostgreSQL Project will not promise to
provide
All,
Gabrielle of PDXPUG volunteered that PUG to hold a "code sprint" in
coordination with a commitfest sometime soon. For that event, the
PDXPUG members would take on a dozen or so patches, compile and review
them and submit the results.
The reason I mention this here is that they would ne
On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote:
All,
I'd suggest that we publish an official policy, with the following
dates for "EOL":
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
"After the above dates, t
Josh Berkus writes:
> I'd suggest that we publish an official policy, with the following dates
> for "EOL":
> 7.4 2009-08-01
> 8.0 2010-02-01
> 8.1 2011-01-01
> 8.2 2012-01-01
> 8.3 2013-03-01
> 8.4 2014-08-01
I have no objection to setting an EOL date for 7.4 now, but I think it
is
David E. Wheeler wrote:
> On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote:
>
> > All,
> >
> > I'd suggest that we publish an official policy, with the following
> > dates for "EOL":
> >
> > 7.4 2009-08-01
> > 8.0 2010-02-01
> > 8.1 2011-01-01
> > 8.2 2012-01-01
> > 8.3 2013-03-01
> > 8.
On Jul 10, 2009, at 6:01 PM, Josh Berkus wrote:
All,
I'd suggest that we publish an official policy, with the following
dates for "EOL":
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
"After the above dates,
Tom Lane wrote:
But on the whole I think we should NOT have such a policy, at all.
If we'd enunciated such a thing in 2005, we'd still be on the hook to
support 8.0 on Windows; or else have had to go back on our word. The
truth of the matter is that the community will make reasonable efforts
t
Andrew Dunstan writes:
> I think we can avoid most of these problems by making a "best effort"
> policy rather than a hard promise. But it can be moderately specific
> about what we will make best efforts towards. I agree that anyone who
> wants a hard promise should be getting commercial supp
Tom Lane wrote:
Andrew Dunstan writes:
I think we can avoid most of these problems by making a "best effort"
policy rather than a hard promise. But it can be moderately specific
about what we will make best efforts towards. I agree that anyone who
wants a hard promise should be getting co
On Jul 10, 2009, at 5:39 PM, Tom Lane wrote:
I don't mind the idea of saying "our intention is to support new
releases for about five years", or something equally squishy.
But a list of dates in black and white does not look reasonable,
especially not dates that are four or five years out for ve
On Fri, 10 Jul 2009 19:51:31 -0400
Tom Lane wrote:
> Josh Berkus writes:
> > I'd suggest that we publish an official policy, with the following dates
> > for "EOL":
>
> I have no objection to setting an EOL date for 7.4 now, but I think it
> is premature to set EOL dates for later versions. I
We just ran into a case where we were performing two concurrent index
builds on two different tables in two different schemas in the same
database (no relational constraints between them).
One of the index builds locked on the other.
The first index build started...
The second index build st
Theo Schlossnagle writes:
> I would think it would be txns that would be reading that table, but
> I'm thinking it is a bit to aggressive. Am I reading the code wrong
> there? I'm thinking it should be more selective about vxids it
> chooses to block on. I'd expect it to block on vxids to
On Fri, Jul 10, 2009 at 2:44 PM, Jaime
Casanova wrote:
> On Fri, Jul 10, 2009 at 10:22 AM, Robert Haas wrote:
>> I took a look at this and it seems that #3 can be implemented with
>> essentially no additional code (the handful of lines I added where
>> more than balanced out by some simplifications
On Fri, Jul 10, 2009 at 2:48 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> You do, but it's been pretty rare in my experience, and we're
>> considering alternatives which give a lot less flexibility that this.
>
> I dunno about "considering". We've already wasted vastly more time on
> this th
On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:
Theo Schlossnagle writes:
I would think it would be txns that would be reading that table, but
I'm thinking it is a bit to aggressive. Am I reading the code wrong
there? I'm thinking it should be more selective about vxids it
chooses to block o
38 matches
Mail list logo
