On Mon, Oct 14, 2019 at 5:36 AM Alexander Korotkov
wrote:
> On Sun, Oct 13, 2019 at 5:24 AM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > This patch also changes the way timestamp to timestamptz cast works.
> > > Previously it did timestamp2tm() then tm2timestamp(). Instead, after
> > >
On Sun, Oct 13, 2019 at 5:24 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > This patch also changes the way timestamp to timestamptz cast works.
> > Previously it did timestamp2tm() then tm2timestamp(). Instead, after
> > timestamp2tm() it calculates timezone offset and applies it to
> > or
Alexander Korotkov writes:
> This patch also changes the way timestamp to timestamptz cast works.
> Previously it did timestamp2tm() then tm2timestamp(). Instead, after
> timestamp2tm() it calculates timezone offset and applies it to
> original timestamp value. I hope this is correct.
I'd wonde
On Thu, Oct 3, 2019 at 4:48 PM Robert Haas wrote:
> On Tue, Oct 1, 2019 at 1:41 PM Alexander Korotkov
> wrote:
> > So, basically standard requires us to suppress any error happening in
> > filter expression.
>
> Sounds like the standard is dumb, then. :-)
>
> > But as I wrote before suppression o
On Tue, Oct 1, 2019 at 1:41 PM Alexander Korotkov
wrote:
> So, basically standard requires us to suppress any error happening in
> filter expression.
Sounds like the standard is dumb, then. :-)
> But as I wrote before suppression of errors in
> datetime comparison may lead to surprising results.
On Mon, Sep 30, 2019 at 10:56 PM Robert Haas wrote:
> On Sun, Sep 29, 2019 at 10:30 AM Alexander Korotkov
> wrote:
> > So, jsonpath behaves like 100 is not greater than 2020. This
> > looks like plain false. And user can't expect that unless she is
> > familiar with our particular issues.
On Sun, Sep 29, 2019 at 10:30 AM Alexander Korotkov
wrote:
> So, jsonpath behaves like 100 is not greater than 2020. This
> looks like plain false. And user can't expect that unless she is
> familiar with our particular issues. Now I got opinion that such
> errors shouldn't be suppressed.
On Fri, Sep 27, 2019 at 6:58 PM Nikita Glukhov wrote:
> On Thu, Sep 26, 2019 at 2:57 AM Tom Lane
> wrote:
> > * More generally, it's completely unclear why some error conditions
> > are thrown as errors and others just result in returning *have_error.
> > In particular, it seems weird that some
