From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: btree_gin and btree_gist for enums |
Date: | 2017-02-24 01:34:27 |
Message-ID: | 25226.1487900067@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On 02/23/2017 04:41 PM, Tom Lane wrote:
>> BTW, while I'm looking at this ... isn't gin_enum_cmp broken on its face?
> Yes, that's what I'm trying to fix.
I'd forgotten where this thread started. For a minute there I thought
we had a live bug, rather than a deficiency in code-under-development.
After thinking about that, I believe that enum_cmp_internal is a rather
considerable hazard. It might not be our only function that requires
fcinfo->flinfo cache space just some of the time not all the time, but
I don't recall anyplace else that could so easily undergo a reasonable
amount of testing without *ever* reaching the case where it requires
that cache space. So I'm now worried that it wouldn't be too hard for
such a bug to get past us.
I think we should address that by adding a non-bypassable Assert that
the caller did provide flinfo, as in the attached.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
assert-that-enum-comparator-can-use-cache.patch | text/x-diff | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2017-02-24 01:38:36 | Re: Range Partitioning behaviour - query |
Previous Message | Amit Langote | 2017-02-24 01:17:23 | Re: Range Partitioning behaviour - query |