From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Dilger <hornschnorter(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: WIP: BRIN multi-range indexes |
Date: | 2018-02-06 00:25:00 |
Message-ID: | 3e924a4c-6ca0-cc10-aebb-5004fc002800@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/06/2018 12:40 AM, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2018-02-06 00:45:37 | Re: Better Upgrades |
Previous Message | David G. Johnston | 2018-02-06 00:21:13 | Re: Better Upgrades |