2016-07-05 4:33 GMT+02:00 David G. Johnston <david.g.johns...@gmail.com>:
> On Mon, Jul 4, 2016 at 8:39 PM, Andreas 'ads' Scherbaum < > adsm...@wars-nicht.de> wrote: > >> On 04.07.2016 18:37, Pavel Stehule wrote: >> >>> >>> 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. >>> >> >> Obviously not enough, because it allows invalid dates. I'd say that the >> current to_date() merely validates the input format for string parsing, and >> that the date is in range. But there is not much validation on the date >> itself. >> >> So the name can't be "strict" because of the conflict with "NULL" >> handling, and you don't like "valid" - what other options do you offer? > > > We don't have to change the name...we could do something like how > RegularExpressions work - like (?i) - and just add a new modifier code. > > '~YYYY-MI-DD' --that's a leading tilde, could be anything - even > something like "HMYYYY-MI-DD" for "historical mode" > > Also, see this thread of a few weeks ago for related material: > > > https://www.postgresql.org/message-id/1873520224.1784572.1465833145330.JavaMail.yahoo%40mail.yahoo.com > > It seems that fixing it is back on the table, possibly even for 9.6 since > this is such a hideous bug - one that closely resembles a cockroach ;) > > WRT to the 2014 "reject out-of-range dates" thread, I'm kinda surprised > that we didn't just set the date to be the minimum or maximum allowable > date back in 9.2 instead of rejecting it... > > I'd be more inclined to add another argument if it was basically an enum. > > to_date(text, format, format_style) > > This at least opens the door for future enhancements that are associated > with named styles. I could imagine an "exact" format that also allows for > something like regexp character classes so that one can write: > "YYYY[:SEP:]MM[:SEP:]DD" to keep exact matches but accommodate variations > on what people type as a separator e.g. [.-/] > > format_style=>historical would invoke today's behaviors > this is compatibility break - the question is "can we break it?" Pavel > > David J. > >
