From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: Mark Dilger <hornschnorter@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-hackers@postgreSQL.org
Subject: Re: WIP: BRIN multi-range indexes
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>
Comments: In-reply-to Tomas Vondra <tomas.vondra@2ndquadrant.com>
	message dated "Mon, 05 Feb 2018 21:59:48 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <22673.1517874015.1@sss.pgh.pa.us>
Date: Mon, 05 Feb 2018 18:40:15 -0500
Message-ID: <22674.1517874015@sss.pgh.pa.us>
Precedence: bulk

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