From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: truncating timestamps on arbitrary intervals |
Date: | 2021-04-09 20:02:47 |
Message-ID: | f90d3c1a-42d4-a60f-af88-e6f819f21648@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30.03.21 18:50, John Naylor wrote:
> On Sat, Mar 27, 2021 at 1:06 PM Justin Pryzby <pryzby(at)telsasoft(dot)com
> <mailto:pryzby(at)telsasoft(dot)com>> wrote:
> >
> > The current docs seem to be missing a "synopsis", like
> >
> > +<synopsis>
> > +date_trunc(<replaceable>stride</replaceable>,
> <replaceable>timestamp</replaceable>, <replaceable>origin</replaceable>)
> > +</synopsis>
>
> The attached
> - adds a synopsis
> - adds a bit more description to the parameters similar to those in
> date_trunc
> - documents that negative intervals are treated the same as positive ones
>
> Note on the last point: This just falls out of the math, so was not
> deliberate, but it seems fine to me. We could ban negative intervals,
> but that would possibly just inconvenience some people unnecessarily. We
> could also treat negative strides differently somehow, but I don't
> immediately see a useful and/or intuitive change in behavior to come of
> that.
committed
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-04-09 20:27:42 | Re: WIP: WAL prefetch (another approach) |
Previous Message | Mark Dilger | 2021-04-09 18:50:32 | Re: pg_amcheck contrib application |