On Wednesday, August 17, 2016 5:15 PM, Artur Zakirov <a.zaki...@postgrespro.ru> 
>I attached new patch "0001-to-timestamp-format-checking-v2.patch". It 
>fixes behaviour for Amul's scenarious:

>> Following are few scenarios where we break existing behaviour:
>> SELECT TO_TIMESTAMP('2015-12-31 13:43:36', 'YYYY MM DD HH24 MI SS');
>> SELECT TO_TIMESTAMP('2011$03!18 23_38_15', 'YYYY-MM-DD HH24:MI:SS');
>> SELECT TO_TIMESTAMP('2011*03*18 23^38&15', 'YYYY-MM-DD HH24:MI:SS');
>> SELECT TO_TIMESTAMP('2011*03!18 #%23^38$15', 'YYYY-MM-DD$$$HH24:MI:SS');
>> But current patch behaviour is not that much bad either at least we have 
>> errors, but I am not sure about community acceptance.
>> I would like to divert communities' attention on following case:
>> SELECT TO_TIMESTAMP('2013--10-01', 'YYYY-MM-DD');
>For queries above the patch gives an output without any error.
>> Another is, shouldn’t we have error in following cases?
>> SELECT TO_TIMESTAMP('2016-06-13 99:99:99', 'YYYY-MM-DD HH24:MI:SS');
>> SELECT TO_TIMESTAMP('2016-02-30 15:43:36', 'YYYY-MM-DD HH24:MI:SS');
>I attached second patch "0002-to-timestamp-validation-v2.patch". With it 
>PostgreSQL perform additional checks for date and time. But as I wrote 
>there is another patch in the thread "to_date_valid()" wich differs from 
>this patch.


Hmm. I haven't really looked into the code, but with applying both patches it 
looks precisely imitate Oracle's behaviour. Thanks.

Amul Sul

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to