Subject: Re: WIP: BRIN multi-range indexes
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mark Dilger <hornschnorter@gmail.com>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-hackers@postgreSQL.org
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>
 <22674.1517874015@sss.pgh.pa.us>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <3e924a4c-6ca0-cc10-aebb-5004fc002800@2ndquadrant.com>
Date: Tue, 6 Feb 2018 01:25:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <22674.1517874015@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 02/06/2018 12:40 AM, Tom Lane wrote:
> 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.
> 

Works for me. Ripping out the two opclasses from the patch is trivial.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services