On Fri, Jun 24, 2016 at 5:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford >> <scrawf...@pinpointresearch.com> wrote: >>> To me, 2016-02-30 is an invalid date that should generate an error. > >> I don't particularly disagree with that, but on the other hand, as >> mentioned earlier, to_timestamp() is here for Oracle compatibility, >> and if it doesn't do what Oracle's function does, then (1) it's not >> useful for people migrating from Oracle and (2) we're making up the >> behavior out of whole cloth. I think things that we invent ourselves >> should reject stuff like this, but in a compatibility function we >> might want to, say, have compatibility. > > Agreed, mostly, but ... how far are we prepared to go on that? The one > thing I know about that is different from Oracle and is not something that > most people would consider clearly wrong is the behavior of the FM prefix. > We think it's a prefix that modifies only the next format code; they think > it's a toggle. If we make that act like Oracle, we will silently break an > awful lot of applications, and there will be *no way* to write code that > is correct under both interpretations. (And no, I do not want to hear > "let's fix it with a GUC".) So I'm afraid we're between a rock and a hard > place on that one --- but if we let that stand, the argument that Oracle's > to_timestamp should be treated as right by definition loses a lot of air.
Well, I think that you're making several logical jumps that I personally would decline to make. First, I don't think every issue with these functions needs to be handled in the same way as every other. Just because we're willing or unwilling to break compatibility in one area doesn't mean we have to make the same decision in every case. We're allowed to take into effect the likely impact of making a given change in deciding whether it's worth it. Second, if in one or more areas we decide that a hard backward compatibility break would be too painful, then I think it's a good idea to ask ourselves how we could ease the migration pain for people. And I'd phrase that as an open-ended question rather than "should we add a GUC?". For example, one idea here is to create a to_timstamp_old() function that retains the existing behavior of to_timestamp() without any change, and then add a new to_timestamp() function and fix every Oracle incompatibility we can find as thoroughly as we can do in one release cycle. So we fix this whitespace stuff, we fix the FM modifier, and anything else that comes up, we fix it all. Then, if people run into trouble with the new behavior when they upgrade, we tell them that they can either fix their application or, if they want the old behavior, they can use to_timestamp_old(). We can also document the differences between to_timestamp() and to_timestamp_old() so that people can easily figure out whether those differences are significant to them. Another idea is to add an optional third argument to to_timestamp() that can be used to set compatibility behaviors. I'm not altogether convinced that it's worth the effort to provide lots of backward-compatibility here. Presumably, only a small percentage of people use to_timestamp(), and only a percentage of those are going to rely on the details we're talking about changing. So it might be that if we just up and change this, a few people will be grumpy and then they'll update their code and that will be it. On the other hand, maybe it'll be a real pain in the butt for lots of people and we'll lose users. I don't know how to judge how significant these changes will be to users, and I think that the level of impact does matter in deciding what to do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
