Re: [HACKERS] Bug in to_timestamp(). - Mailing list pgsql-hackers

On Sun, Jul 22, 2018 at 6:22 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Sat, Jul 21, 2018 at 2:34 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
>>
>> So, as I get from this thread, current patch brings these function very close to Oracle behavior.  The only
divergencefound yet is related to handling of unmatched tails of input strings (Oracle throws an error while we swallow
thatsilently) [1].  But this issue can be be addressed by a separate patch. 
>>
>> Patch seems to be in a pretty good shape.  So, the question is whether there is a consensus that we want a
backward-incompatiblebehavior change, which this patch does. 
>>
>> My personal opinion is +1 for committing this, because I see that this patch takes a lot of community efforts on
discussion,coding, review etc.  All these efforts give a substantial result in a patch, which makes behavior more
Oracle-compatibleand (IMHO) more clear. 
>>
>> However, in this thread other opinions were expressed.  In particular, David G. Johnston expressed opinion that we
shouldn'tchange behavior of existing functions, alternatively we could introduce new functions with new behavior.
However,I see David doesn't participate this thread for a quite long time. 
>
> Been lurking about...I'm still of the opinion that this capability should exist in PostgreSQL as "our" function and
notjust as an Oracle compatibility. 

For sure, we're not going to copy Oracle behavior "bug to bug".  But
when users find our behavior to be confusing, there is nothing wrong
to look for Oracle behavior and accept it if it looks good.

> That said the thing I'm most curious to read is the release note entry that would go along with this change that
informsusers what will be changing: silently, visibly, or otherwise. 

I'm sure that release note entry should directly inform users about
backward-incompatible changes in to_timestamp()/to_date() functions.
Users need to be advised to test their applications before porting
them to new major release of PostgreSQL.

> Knowing how much we (don't) diverge from our chosen "standard" after making this change is important but the change
inbehavior from current is, IMO, more important in deciding whether this particular change is worth making. 
> My re-read of the thread the other day left me with a feeling of contentment that this was an acceptable change but I
alsoget the feeling like I'm missing the downside trade-off too...I was hoping your review would help in that regard
butas it did not speak to specific incompatibilities it has not. 

So, if I understand you correctly, downside of trade-off are use-cases
when current behavior looks correct, while patched behavior looks
incorrect.  Yes, while looking at this thread we can't find such
use-cases.  Intuitively, they should be present.  But I thought about
that and didn't find it yet...

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company