On Thu, Jun 23, 2016 at 2:00 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Jun 23, 2016 at 1:46 PM, David G. Johnston > <david.g.johns...@gmail.com> wrote: > >> Sheesh. Who put you in charge of this? You basically seem like you > >> are trying to shut up anyone who supports this change, and I don't > >> think that's right. > > > > I'm all for a change in this area - though I'm not impacted enough to > > actually work on a design proposal. > > You weren't for a change in this area a few emails ago; back then, you > said "I don't see that changing it is a worthwhile endeavor". > I still don't see changing to_timestamp as being the right approach...but that's just my opinion. I do think that this area "text to timestamp conversions" could stand to be improved. I may not have been clear on that distinction. But changing the behavior of a function that has been around since 2000 seems to be just asking for trouble. > > And I'm not sure how asking for ideas > > constitutes trying to shut people up. Especially since if no one does > float > > a proposal we'll simply have this discussion next year when someone new > > discovers how badly behaved this function is. > > In my opinion, telling people that their emails are not constructive > and that no change is possible for 9.6 is pretty much the same thing > as trying to shut people up. And that's what you did. > I guess I should be a bit more careful to make sure that two separate responses on different aspects of a topic cannot be so easily construed as "this thread is pointless". To be clear I did and still do believe that getting a change in this area into 10.0 is worthwhile; and that our policy (and present circumstances) appears to preclude this changing in 9.6. But as noted below this is just an observation. > >> My main point is that I'm inclined to deprecate it. > >> > >> I can almost guarantee that would make a lot of users very unhappy. > >> This function is widely used. > > > > Tell people not to use. We'd leave it in, unchanged, on backward > > compatibility grounds. This seems like acceptable behavior for the > project. > > Am I mistaken? > > Yes. We're not going to deprecate widely-used functionality. We > might, however, fix it, contrary to your representations upthread. > At this point I feel you are cherry-picking my words to fit your present feelings. I stand by everything I've written upthread regarding deprecation and fixing. I'm personally in favor of the former. I'll add that you are a committer, I am not. The one thing going for change is if we indeed exactly match the reference behavior and then document it as being a compatibility function. I hadn't fully pondered this goal and how its plays into changing 16 year old behavior. Obviously a new name for the function doesn't cut it in this scenario. > >> > My second point is if you are going to use this badly designed > function > >> > you > >> > need to protect yourself. > >> > >> I agree that anyone using this function should test their format > >> strings carefully. > >> > >> > My understanding is that is not going to change for 9.6. > >> > >> That's exactly what is under discussion here. > >> > > > > 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. > > Thank You. I still conclude that given the general lack of complaints, the fact we are at beta2, the age of the feature and nature of the "bug", and the non-existence of a working patch even for HEAD, that 9.6 is not going to see this behavior changed and you will be loath to back-patch a fix once 9.6 becomes stable. I'll admit the possibility does exist but am not all that keen on couching every statement of this form I make. If you find my interpretation to be overly conservative then voice yours. I've been doing this a while without any complaint so I'm apparently right considerably more often than I am wrong. You are welcome to say that you'd consider a patch for 9.6 if its received by the end of beta2 - or that you are working on one yourself and hope to have it possibly included in time for beta3. I'll go buy and then eat a hat if this happens and we have backward incompatibility note for to_timestamp in the 9.6 docs. David J.
