Horton

Re: btree_gin and btree_gist for enums

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-02-24T01:34:27Z
Lists: pgsql-hackers

Attachments

Andrew Dunstan <andrew.dunstan@2ndquadrant.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

Commits

  1. Add btree_gin support for enum types

  2. Add btree_gist support for enum types.

  3. Use CallerFInfoFunctionCall with btree_gist for numeric types

  4. Add a direct function call mechanism using the caller's context.

  5. Add support for EUI-64 MAC addresses as macaddr8

  6. Add an Assert that enum_cmp_internal() gets passed an FmgrInfo pointer.