Re: to_date_valid()

On 04.07.2016 05:51, Pavel Stehule wrote:
>
>
> 2016-07-04 5:19 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com
> <mailto:pavel.stehule@gmail.com>>:
>
>
>
>     2016-07-04 4:25 GMT+02:00 Craig Ringer <craig@2ndquadrant.com
>     <mailto:craig@2ndquadrant.com>>:
>
>         On 3 July 2016 at 09:32, Euler Taveira <euler@timbira.com.br
>         <mailto:euler@timbira.com.br>> wrote:
>
>             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:

postgres=# select to_date_valid(NULL, NULL); to_date_valid
---------------

(1 row)

--             Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project