Re: Support for jsonpath .datetime() method

2019-09-27 Thread Nikita Glukhov
On 25.09.2019 22:55, Alexander Korotkov wrote: On Mon, Sep 23, 2019 at 10:05 PM Alexander Korotkov wrote: I've reordered the patchset. I moved the most debatable patch, which introduces and RR and changes parsing of YYY, YY and Y to the end. I think we have enough of time in this

Re: Support for jsonpath .datetime() method

2019-09-25 Thread Alexander Korotkov
On Mon, Sep 23, 2019 at 10:05 PM Alexander Korotkov wrote: > I've reordered the patchset. I moved the most debatable patch, which > introduces and RR and changes parsing of YYY, YY and Y to the > end. I think we have enough of time in this release cycle to decide > whether we want this. >

Re: Support for jsonpath .datetime() method

2019-08-18 Thread Alexander Korotkov
On Tue, Aug 13, 2019 at 12:08 AM Alexander Korotkov wrote: > On Thu, Aug 1, 2019 at 1:31 PM Thomas Munro wrote: > > On Sat, Jul 27, 2019 at 2:43 AM Andrew Dunstan > > wrote: > > > On 7/23/19 6:48 PM, Nikita Glukhov wrote: > > > > Some concrete pieces of review: > > > >> + > > > >> +

Re: Support for jsonpath .datetime() method

2019-08-12 Thread Alexander Korotkov
On Thu, Aug 1, 2019 at 1:31 PM Thomas Munro wrote: > On Sat, Jul 27, 2019 at 2:43 AM Andrew Dunstan > wrote: > > On 7/23/19 6:48 PM, Nikita Glukhov wrote: > > > Some concrete pieces of review: > > >> + > > >> +FF1 > > >> +decisecond (0-9) > > >> + > > >> > > >>

Re: Support for jsonpath .datetime() method

2019-08-01 Thread Thomas Munro
On Sat, Jul 27, 2019 at 2:43 AM Andrew Dunstan wrote: > On 7/23/19 6:48 PM, Nikita Glukhov wrote: > > Some concrete pieces of review: > >> + > >> +FF1 > >> +decisecond (0-9) > >> + > >> > >> Let's not use such weird terms as "deciseconds". We could say > >>

Re: Support for jsonpath .datetime() method

2019-07-26 Thread Andrew Dunstan
On 7/23/19 6:48 PM, Nikita Glukhov wrote: > Some concrete pieces of review: >> + >> +FF1 >> +decisecond (0-9) >> + >> >> Let's not use such weird terms as "deciseconds". We could say >> "fractional seconds, 1 digit" etc. or something like that. > And what about

Re: Support for jsonpath .datetime() method

2019-07-26 Thread Andrew Dunstan
On 7/24/19 4:25 PM, Peter Eisentraut wrote: > On 2019-07-24 00:48, Nikita Glukhov wrote: >> It seems that our YY works like RR should: >> >> SELECT to_date('69', 'YY'); >> to_date >> >> 2069-01-01 >> (1 row) >> >> SELECT to_date('70', 'YY'); >> to_date >> >>

Re: Support for jsonpath .datetime() method

2019-07-24 Thread Peter Eisentraut
On 2019-07-24 00:48, Nikita Glukhov wrote: > It seems that our YY works like RR should: > > SELECT to_date('69', 'YY'); > to_date > > 2069-01-01 > (1 row) > > SELECT to_date('70', 'YY'); > to_date > > 1970-01-01 > (1 row) > > But by the standard first two

Re: Support for jsonpath .datetime() method

2019-07-24 Thread Alexander Korotkov
On Wed, Jul 24, 2019 at 1:50 AM Nikita Glukhov wrote: > So it's unclear what we should do: > - implement YY and RR strictly following the standard only in .datetime() > - fix YY implementation in to_date()/to_timestamp() and implement RR > - use our non-standard templates in .datetime() Also

Re: Support for jsonpath .datetime() method

2019-07-23 Thread Nikita Glukhov
On 23.07.2019 16:44, Peter Eisentraut wrote: I think the best way forward here is to focus first on patch 0002 and get the additional format templates in, independent of any surrounding JSON functionality. In particular, remove parse_datetime() and all the related API changes, then it becomes

Re: Support for jsonpath .datetime() method

2019-07-23 Thread Peter Eisentraut
I think the best way forward here is to focus first on patch 0002 and get the additional format templates in, independent of any surrounding JSON functionality. In particular, remove parse_datetime() and all the related API changes, then it becomes much simpler. The codes FF1..FF6 that you added

Re: Support for jsonpath .datetime() method

2019-07-15 Thread Anastasia Lubennikova
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested Hi, In general, the feature looks good. It is consistent with