Bernd Helmle wrote:
--On 22. Januar 2010 15:40:58 +0200 Peter Eisentraut
wrote:
Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.
For someone like me it's har
--On 22. Januar 2010 15:40:58 +0200 Peter Eisentraut
wrote:
Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.
For someone like me it's hard to guess, what "small
On Fri, Jan 22, 2010 at 11:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not sure whether you're stating a position that's been agreed to
>> by -core or some other group, or just expressing your own opinion, but
>> I think feature freeze should be the beginning of the last CommitFest,
>> no
Robert Haas writes:
> I'm not sure whether you're stating a position that's been agreed to
> by -core or some other group, or just expressing your own opinion, but
> I think feature freeze should be the beginning of the last CommitFest,
> not the end.
I think traditionally we understood "feature
On fre, 2010-01-22 at 15:10 +, Simon Riggs wrote:
> I merely ask that you consider the non-zero cost of such changes as
> well
> as the benefit. Not all change is worthwhile, even if the change can
> be
> made quickly and with little effect on the stability of the software.
Right, that's why I
On Fri, 2010-01-22 at 16:50 +0200, Peter Eisentraut wrote:
> On fre, 2010-01-22 at 14:22 +, Simon Riggs wrote:
> > "Stable software" isn't just software that doesn't break, it requires
> > IIABDFI as well.
>
> Yeah, I don't buy that. That would mean that you can never do
> maintenance, refact
On fre, 2010-01-22 at 14:22 +, Simon Riggs wrote:
> "Stable software" isn't just software that doesn't break, it requires
> IIABDFI as well.
Yeah, I don't buy that. That would mean that you can never do
maintenance, refactoring, or polishing. You basically just wait for the
system to die a d
2010/1/22 Devrim GÜNDÜZ :
> On Fri, 2010-01-22 at 09:10 -0500, Robert Haas wrote:
>> I'm not sure whether you're stating a position that's been agreed to
>> by -core or some other group, or just expressing your own opinion, but
>> I think feature freeze should be the beginning of the last CommitFes
On Fri, Jan 22, 2010 at 9:22 AM, Simon Riggs wrote:
> On Thu, 2010-01-21 at 23:22 +0200, Peter Eisentraut wrote:
>> On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
>> > Robert Haas writes:
>> > > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut
>> > > wrote:
>> > >> Here is a small patch th
On Fri, 2010-01-22 at 09:10 -0500, Robert Haas wrote:
> I'm not sure whether you're stating a position that's been agreed to
> by -core or some other group, or just expressing your own opinion, but
> I think feature freeze should be the beginning of the last CommitFest,
> not the end.
Was is decl
Robert Haas wrote:
On Fri, Jan 22, 2010 at 8:40 AM, Peter Eisentraut wrote:
On tor, 2010-01-21 at 18:05 -0500, Andrew Dunstan wrote:
Well, we used to have the idea of a feature freeze ... is that going
to apply at the end of the commitfest?
Feature freeze was used to discoura
On Thu, 2010-01-21 at 23:22 +0200, Peter Eisentraut wrote:
> On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
> > >> Here is a small patch that changes the error message
> > >>
> > >> duplicate key value vi
On Fri, Jan 22, 2010 at 8:40 AM, Peter Eisentraut wrote:
> On tor, 2010-01-21 at 18:05 -0500, Andrew Dunstan wrote:
>> Well, we used to have the idea of a feature freeze ... is that going
>> to apply at the end of the commitfest?
>
> Feature freeze was used to discourage the submission of very big
On tor, 2010-01-21 at 19:45 -0500, Robert Haas wrote:
> Well, that does seem to be endorsing a sort of two-tiered system.
In those words, yes, it's a multi-tiered system. The aim of the commit
fests is to make the "lower" tier more effective, but not necessarily to
bring the "upper" tier to a nea
On tor, 2010-01-21 at 18:05 -0500, Andrew Dunstan wrote:
> Well, we used to have the idea of a feature freeze ... is that going
> to apply at the end of the commitfest?
Feature freeze was used to discourage the submission of very big patches
shortly before beta. The commit fest process has IMO al
Tom Lane wrote:
> Now your original posts back in December were okay, since you were
> just letting people know that you intended to work on this over a
> long period. But IIRC you've made more than one post with actual
> code in it that you seemed to be hoping people would review, and
> that I
On Thu, Jan 21, 2010 at 5:35 PM, Peter Eisentraut wrote:
> On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote:
>> But let me ask this. For which
>> release were you hoping to make this change? If 9.0, then it seems to
>> me that you've missed the deadline, which - according to my
>> understand
On Thu, Jan 21, 2010 at 7:11 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> If you want an example of something I *do* have a process problem
>>> with, it's Kevin Grittner's attempts
>
>> Hmmm Plural? I've made exactly one post on the subject since
>> the CF started,
"Kevin Grittner" writes:
> Tom Lane wrote:
>> If you want an example of something I *do* have a process problem
>> with, it's Kevin Grittner's attempts
> Hmmm Plural? I've made exactly one post on the subject since
> the CF started, unless you count review of Markus's dtester code,
> whic
Tom Lane wrote:
> If you want an example of something I *do* have a process problem
> with, it's Kevin Grittner's attempts
Hmmm Plural? I've made exactly one post on the subject since
the CF started, unless you count review of Markus's dtester code,
which he posted before the CF but didn
Tom Lane wrote:
> If you want an example of something I *do* have a process problem
> with, it's Kevin Grittner's attempts to get people to put a
> significant number of cycles into thinking about true
> serializability.
> Right now is not the time for that to be happening. I've been
> politely
Andrew Dunstan writes:
> Peter Eisentraut wrote:
>> But I don't think that should mean everyone has to drop everything when
>> the clock strikes midnight and must now only look at things that the
>> magic commitfest page has pre-approved.
> Well, we used to have the idea of a feature freeze ...
On Jan 21, 2010, at 3:05 PM, Andrew Dunstan wrote:
> Well, we used to have the idea of a feature freeze ... is that going to apply
> at the end of the commitfest?
>
> I generally agree that we need to have a bit of wiggle room at this stage -
> small and non-controversial items can be allowed t
Peter Eisentraut wrote:
But I don't think that should mean everyone has to drop everything when
the clock strikes midnight and must now only look at things that the
magic commitfest page has pre-approved.
Well, we used to have the idea of a feature freeze ... is that going to
apply at t
On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote:
> But let me ask this. For which
> release were you hoping to make this change? If 9.0, then it seems to
> me that you've missed the deadline, which - according to my
> understanding of the agreed-upon schedule - was six days ago.
By that log
On Thu, Jan 21, 2010 at 4:24 PM, Peter Eisentraut wrote:
>> Why bother?
>
> Because unique constraints and primary keys are different things and it
> would be slightly less confusing that way.
I don't really see why it would be any less confusing. You could
argue that someone might not know that
On tor, 2010-01-21 at 16:29 -0500, Tom Lane wrote:
> regression=# alter table foo add primary key (f1);
> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "foo_pkey"
> for table "foo"
> ERROR: could not create unique index "foo_pkey"
> DETAIL: Key (f1)=(1) is duplicated.
He he,
Peter Eisentraut writes:
> On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
>> This patch fails to cover all cases (index build being the obvious
>> omission, but I think there might be other paths as well where the
>> information is not so readily available).
> This is the user-visible error m
On tor, 2010-01-21 at 15:47 -0500, Robert Haas wrote:
> On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
> > Here is a small patch that changes the error message
> >
> >duplicate key value violates unique constraint "%s"
> >
> > into
> >
> >duplicate key value violates primary key
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
> >> Here is a small patch that changes the error message
> >>
> >> duplicate key value violates unique constraint "%s"
> >>
> >> into
> >>
> >> duplicate key
Robert Haas writes:
> On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
>> Here is a small patch that changes the error message
>>
>> duplicate key value violates unique constraint "%s"
>>
>> into
>>
>> duplicate key value violates primary key "%s"
>>
>> when the constraint is in
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
> Here is a small patch that changes the error message
>
> duplicate key value violates unique constraint "%s"
>
> into
>
> duplicate key value violates primary key "%s"
>
> when the constraint is in fact a primary key.
>
> Comments?
Here is a small patch that changes the error message
duplicate key value violates unique constraint "%s"
into
duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
PS: Yes, this would need a handful of regression test updates if
accepte
33 matches
Mail list logo
