Re: Partitioning by month causing an error?

On 12/20/19 10:10 PM, Tom Lane wrote:
> Ron <ronljohnsonjr(at)gmail(dot)com> writes:
>> On 12/20/19 8:59 PM, Tom Lane wrote:
>>> The rule is that a range partition from A to B covers values A <= X < B.
>> If I were to ask to count *from* 1 *to* 100, you'd count from 1 to 100,
>> *not* 1 to 99.  Who decided to arbitrarily break a grammatical rule we
>> (native English speakers, and I bet everyone else, too) all learn as
>> children, causing all sorts of needless confusion and breakage?
> This rule breaks fewer things than a rule of A <= X <= B would. In
> particular, for more-or-less-continuous values like float8s or timestamps,
> you really really don't want to have to write down
> the-last-possible-value-before-the-start-of-the-next-partition.

Why not?  For 20+ years (not on Postgres) I've been specifying partition
limits where the upper limits are the edge of timestamps (octaword integers
counting the number of 100ns ticks since November 17, 1858), and have
*never* had a problem:
IN ETC_TRAN_DETAIL_201909_UA WITH LIMIT OF '2019-09-30 23:59:59.99',
IN ETC_TRAN_DETAIL_201910_UA WITH LIMIT OF '2019-10-31 23:59:59.99',
IN ETC_TRAN_DETAIL_201911_UA WITH LIMIT OF '2019-11-30 23:59:59.99',
IN ETC_TRAN_DETAIL_201912_UA WITH LIMIT OF '2019-12-31 23:59:59.99',
IN ETC_TRAN_DETAIL_202001_UA WITH LIMIT OF '2020-01-31 23:59:59.99',
IN ETC_TRAN_DETAIL_202002_UA WITH LIMIT OF '2020-02-28 23:59:59.99',
etc, etc, etc

Of course, I've also never partitioned a table on a float, thinking that's
utterly daft.

--
Angular momentum makes the world go 'round.