Re: [HACKERS] Bug in to_timestamp().

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.

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. 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.

David J.