On Thu, Jun 23, 2016 at 02:00:49PM -0400, Robert Haas wrote:
> > Ok. I'm having trouble seeing this justified as a bug fix - the docs
> > clearly state our behavior is intentional. Improved behavior, yes, but
> > that's a feature and we're in beta2. Please be specific if you believe I've
> > misinterpreted project policies on this matter.
>
> I would not vote to back-patch a change in this area because I think
> that could break SQL code that works today. But I think the current
> behavior is pretty well indefensible. It's neither intuitive nor
> compatible with Oracle. And there is plenty of existing precedent for
> making this sort of change during the beta period. We regard it as a
> bug fix which is too dangerous to back-patch; therefore, it is neither
> subject to feature freeze nor does it go into existing stable
> releases. Whether to treat this particular issue in that particular
> way is something that needs to be hammered out in discussion. Tom
> raises the valid point that we need to make sure that we've thoroughly
> studied this issue and fixed all of the related cases before
> committing anything -- we don't want to change the behavior in
> 9.6beta, release 9.6, and then have to change it again for 9.7. But
> there is certainly no project policy which says we can't change this
> now for 9.6 if we decide that (1) the current behavior is wrong and
> (2) we are quite sure we know how to fix it.
If you are not going to backpatch this for compatibility reasons, I
don't think changing it during beta makes sense either because you open
the chance of breaking applications that have already been tested on
earlier 9.6 betas. This would only make sense if the to_timestamp bugs
were new in 9.6.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +