| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| 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-05 23:40:15 |
| Message-ID: | 22674.1517874015@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Edmund Horner | 2018-02-05 23:50:40 | psql tab completion vs transactions |
| Previous Message | Robert Haas | 2018-02-05 22:34:12 | Re: Crash in partition-wise join involving dummy partitioned relation |