I wrote:
> I think you have a point that it could be stated more simply and
generally. I'll try to move in that direction.
On second thought, I don't think this is helpful. Concrete examples are
easier to reason about.
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Sep 23, 2021 at 4:13 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
>
> Hi John,
>
> > Any thoughts on the doc patch?
>
> It so happened that I implemented a similar feature in TimescaleDB [1].
>
> I discovered that it's difficult from both developer's and user's
> perspectives t
Hi hackers,
> the function works as if it was timestamp. E.g. time_bucket_ng("3
> month", "2021 Oct 03 12:34:56 TZ") = "2021 Jan 01 00:00:00 TZ" no
That was a typo. What I meant was:
time_bucket_ng("3 month", "2021 Feb 03 12:34:56 TZ")
February, not October. Sorry for the confusion.
--
Best r
Hi John,
> Any thoughts on the doc patch?
It so happened that I implemented a similar feature in TimescaleDB [1].
I discovered that it's difficult from both developer's and user's
perspectives to think about the behavior of the function in the
context of given TZ and its complicated rules, as yo
> On Wed, Sep 1, 2021 at 3:25 PM Tom Lane wrote:
> >
> > John Naylor writes:
> > > On Wed, Sep 1, 2021 at 2:44 PM Tom Lane wrote:
> > >> I see that these two answers are both exactly multiples of 24 hours
away
> > >> from the given origin. But if I'm binning on the basis of "days" or
> > >> lar
On Wed, Sep 1, 2021 at 3:25 PM Tom Lane wrote:
>
> John Naylor writes:
> > On Wed, Sep 1, 2021 at 2:44 PM Tom Lane wrote:
> >> I see that these two answers are both exactly multiples of 24 hours
away
> >> from the given origin. But if I'm binning on the basis of "days" or
> >> larger units, I w
On Wed, Sep 1, 2021 at 3:25 PM Tom Lane wrote:
>
> John Naylor writes:
> > On Wed, Sep 1, 2021 at 2:44 PM Tom Lane wrote:
> >> I see that these two answers are both exactly multiples of 24 hours
away
> >> from the given origin. But if I'm binning on the basis of "days" or
> >> larger units, I w
John Naylor writes:
> On Wed, Sep 1, 2021 at 2:44 PM Tom Lane wrote:
>> I see that these two answers are both exactly multiples of 24 hours away
>> from the given origin. But if I'm binning on the basis of "days" or
>> larger units, I would sort of expect to get local midnight, and I'm not
>> ge
On Wed, Sep 1, 2021 at 2:44 PM Tom Lane wrote:
> regression=# set timezone to 'America/New_York';
> SET
> regression=# select date_bin('1 day', '2021-11-01 00:00
+00'::timestamptz, '2021-09-01 00:00 -04'::timestamptz);
> date_bin
>
> 2021-10-31 00:00:00-04
> (1 r
Justin Pryzby writes:
> On Wed, Sep 01, 2021 at 01:26:26PM -0400, John Naylor wrote:
>> I'm not quite willing to bet the answer couldn't change if the timezone
>> changes, but it's possible I'm the one missing something.
> ts=# SET timezone='-12';
> ts=# SELECT date_bin('1hour', '2021-07-01 -1200
On Wed, Sep 01, 2021 at 01:26:26PM -0400, John Naylor wrote:
> On Wed, Sep 1, 2021 at 5:32 AM Aleksander Alekseev
> wrote:
> >
> > By looking at timestamptz_bin() implementation I don't see why it
> > should be STABLE. Its return value depends only on the input values.
> > It doesn't look at the s
John Naylor writes:
> On Wed, Sep 1, 2021 at 5:32 AM Aleksander Alekseev
> wrote:
>> By looking at timestamptz_bin() implementation I don't see why it
>> should be STABLE. Its return value depends only on the input values.
>> It doesn't look at the session parameters. timestamptz_in() and
>> time
On Wed, Sep 1, 2021 at 5:32 AM Aleksander Alekseev
wrote:
>
> By looking at timestamptz_bin() implementation I don't see why it
> should be STABLE. Its return value depends only on the input values.
> It doesn't look at the session parameters. timestamptz_in() and
> timestamptz_out() are STABLE, t
Hi John,
By looking at timestamptz_bin() implementation I don't see why it
should be STABLE. Its return value depends only on the input values.
It doesn't look at the session parameters. timestamptz_in() and
timestamptz_out() are STABLE, that's true, but this is no concern of
timestamptz_bin().
A
John Naylor writes:
> On Tue, Aug 31, 2021 at 3:07 PM Tom Lane wrote:
>> Yeah, you need to bump catversion.
> Done, thanks for confirming.
For future reference --- I think it's potentially confusing to use
the same catversion number in different branches, except for the
short time after a new b
On Tue, Aug 31, 2021 at 3:07 PM Tom Lane wrote:
>
> John Naylor writes:
> > (Starting a new thread for greater visibility)
> > The attached is a fairly straightforward correction. I did want to make
> > sure it was okay to bump the catversion in the PG14 branch also. I've
seen
> > fixes where doi
John Naylor writes:
> (Starting a new thread for greater visibility)
> The attached is a fairly straightforward correction. I did want to make
> sure it was okay to bump the catversion in the PG14 branch also. I've seen
> fixes where doing that during beta was in question.
Yeah, you need to bump
(Starting a new thread for greater visibility)
The attached is a fairly straightforward correction. I did want to make
sure it was okay to bump the catversion in the PG14 branch also. I've seen
fixes where doing that during beta was in question.
--
John Naylor
EDB: http://www.enterprisedb.com
18 matches
Mail list logo
