Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions
Date
Msg-id 20118.1495992147@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] Allow GiST opcalsses without compress\decompres functions  (Andrew Borodin <borodin@octonica.com>)
Responses Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions  (Andrew Borodin <borodin@octonica.com>)
List pgsql-hackers
Andrew Borodin <borodin@octonica.com> writes:
> Maybe we should make compress\decompress functions optional?

1. You'll need to adjust the documentation (gist.sgml) not just the code.

2. If compress/decompress are omitted, then we could support index-only
scans all the time, that is a no-op fetch function would work.  The
patch should cover that interaction too.

3. Personally I wouldn't bother with the separate compressed[] flags,
just look at OidIsValid(giststate->compressFn[i].fn_oid).

4. I don't think you thought very carefully about the combinations
where only one of the two functions is supplied.  I can definitely
see that compress + no decompress could be sensible.  Less sure
about the other case, but why not allow it?  We could just say that
an omitted function is taken to represent a no-op transformation.

Please add this to the next commitfest.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: [HACKERS] logical replication - still unstable after all thesemonths
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] execGrouping.c limit on work_mem