From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Mark Dilger <hornschnorter@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: WIP: BRIN multi-range indexes
Date: Mon, 05 Feb 2018 18:40:15 -0500
Message-ID: <22674.1517874015@sss.pgh.pa.us> (raw)
In-Reply-To: <0afde2fc-e160-004f-8fe2-c65302ac3760@2ndquadrant.com>
References: <20180123200537.gfx5hxcp5k5hktpe@alvherre.pgsql>
<821c4c1d-592e-8916-e323-04607b11777e@2ndquadrant.com>
<c32f9f46-e0ca-0c02-45ec-718dd381f4be@2ndquadrant.com>
<104E8BB8-35FF-4AA8-9871-6AFF04E4CAF3@gmail.com>
<0afde2fc-e160-004f-8fe2-c65302ac3760@2ndquadrant.com>
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> Yeah, that's what I've been wondering about too. There's also this
> comment in nabstime.h:
> /*
> * Although time_t generally is a long int on 64 bit systems, these two
> * types must be 4 bytes, because that's what pg_type.h assumes. They
> * should be yanked (long) before 2038 and be replaced by timestamp and
> * interval.
> */
> But then why adding BRIN opclasses at all? And if adding them, why not
> to test them? We all know how long deprecation takes, particularly for
> data types.
There was some pretty recent chatter about removing these types; IIRC
Andres was annoyed about their lack of overflow checks.
I would definitely vote against adding any BRIN support for these types,
or indeed doing any work on them at all other than removal.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, tomas.vondra@2ndquadrant.com, hornschnorter@gmail.com, alvherre@alvh.no-ip.org
Subject: Re: WIP: BRIN multi-range indexes
In-Reply-To: <22674.1517874015@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox