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". > 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. >> 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. >> > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers