Re: to_date_valid()
| От | Pavel Stehule |
|---|---|
| Тема | Re: to_date_valid() |
| Дата | |
| Msg-id | CAFj8pRD25suv626vN6K0Kz=2W=TBJwoi07DhiWWU5gZZ6KPXhg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: to_date_valid() (Pavel Stehule <pavel.stehule@gmail.com>) |
| Ответы |
Re: to_date_valid()
|
| Список | pgsql-hackers |
2016-07-04 5:19 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:
2016-07-04 4:25 GMT+02:00 Craig Ringer <craig@2ndquadrant.com>:On 3 July 2016 at 09:32, Euler Taveira <euler@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.becauseSELECT to_date('blah', 'pattern', true)is less clear to read thanSELECT 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.RegardsPavel
--
В списке pgsql-hackers по дате отправления: