Re: [HACKERS] Bug in to_timestamp().

On Sun, Jul 22, 2018 at 6:22 PM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Sat, Jul 21, 2018 at 2:34 PM, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>>
>> So, as I get from this thread, current patch brings these function very close to Oracle behavior. The only divergence found yet is related to handling of unmatched tails of input strings (Oracle throws an error while we swallow that silently) [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-incompatible behavior 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-compatible and (IMHO) more clear.
>>
>> However, in this thread other opinions were expressed. In particular, David G. Johnston expressed opinion that we shouldn't change 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 not just 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 informs users 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 in behavior 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 also get the feeling like I'm missing the downside trade-off too...I was hoping your review would help in that regard but as 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