2016-07-04 5:19 GMT+02:00 Pavel Stehule <pavel.steh...@gmail.com>:
>
>
> 2016-07-04 4:25 GMT+02:00 Craig Ringer <cr...@2ndquadrant.com>:
>
>> On 3 July 2016 at 09:32, Euler Taveira <eu...@timbira.com.br> wrote:
>>
>>> On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote:
>>> > The attached patch adds a new function "to_date_valid()" which will
>>> > validate the date and return an error if the input and output date do
>>> > not match. Tests included, documentation update as well.
>>> >
>>> Why don't you add a third parameter (say, validate = true | false)
>>> instead of creating another function? The new parameter could default to
>>> false to not break compatibility.
>>>
>>
>> because
>>
>>
>> SELECT to_date('blah', 'pattern', true)
>>
>> is less clear to read than
>>
>> SELECT to_date_valid('blah', 'pattern')
>>
>> and offers no advantage. It's likely faster to use a separate function
>> too.
>>
>
> personally I prefer first variant - this is same function with stronger
> check.
>
Currently probably we have not two similar function - one fault tolerant
and second stricter. There is only one example of similar behave -
parse_ident with "strict" option.
The three parameters are ok still - so I don't see a reason why we have to
implement new function. If you need to emphasize the fact so behave should
be strict, you can use named parameters
select to_date('blah', 'patter', strict => true)
Regards
Pavel
>
> The name to_date_valid sounds little bit strange - maybe to_date_strict
> should be better.
>
> Regards
>
> Pavel
>
>
>>
>> --
>> Craig Ringer http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Training & Services
>>
>
>
