On 04.07.2016 05:51, Pavel Stehule wrote:

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
        <mailto:eu...@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 
            > 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 |
            instead of creating another function? The new parameter
            could default to
            false to not break compatibility.


            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);

(1 row)

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

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

Reply via email to