On 02-07-2016 22 <tel:02-07-2016%2022>: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)
The new function is not "strict", it just adds a validation step:
I understand - I know, so this has zero relation to function flag STRICT
I don't know if the name "strict" is best, but the name "validate" is not good too. Current to_date does some validations too.
-- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project