On Oct 29, 2010, at 5:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Yeah, I think we're going to have to live with it, at least for 8.4. One could make an argument that 9.0 is new enough we could get away with a small behavior change to avoid a large amount of user confusion. But that may be a self-serving argument based on wanting to tamp down the bug reports rather than a wisely considered policy decision... so I'm not sure I quite buy it.
> Well, tamping down the bug reports is good from the users' point of view
> The argument for not changing it in the back branches is that there
> might be someone depending on the 8.4/9.0 behavior. However, that seems
> moderately unlikely. Also, if we wait, that just increases the chances
> that someone will come to depend on it, and then have a problem when
> they migrate to 9.1. I think the "risk of breakage" argument has a lot
> more force when considering long-standing behaviors than things we just
> recently introduced.
I'm not entirely sure that a behavior we released well over a year ago can be considered "just recently introduced"...
In response to
pgsql-performance by date
|Next:||From: Marti Raudsepp||Date: 2010-10-31 12:13:39|
|Subject: Defaulting wal_sync_method to fdatasync on Linux for 9.1?|
|Previous:||From: Ozer, Pam||Date: 2010-10-29 22:10:16|
|Subject: Re: Slow Query- Bad Row Estimate |
pgsql-bugs by date
|Next:||From: Marcus Wirsing||Date: 2010-10-30 11:07:28|
|Subject: BUG #5733: Strange planer behaviour with inherited tables|
|Previous:||From: Tom Lane||Date: 2010-10-29 21:53:52|
|Subject: Re: [PERFORM] typoed column name, but postgres didn't grump |