On Mon, Jul 10, 2017 at 4:08 PM, Greg Stark <st...@mit.edu> wrote: > One thing I would like to see is features like this added to the > opclasses (or opfamilies?) using standard PG functions that return > standard PG data types. So if each opclass had a function that took > the data type in question and returned a bytea then you could > implement that function using a language you felt like (in theory), > test it using standard SQL, and possibly even find other uses for it.
That seems like a good goal. > That kind of abstraction would be more promising for the future than > having yet another C api that is used for precisely one purpose and > whose definition is "provide the data needed for this usage". Perhaps this is obvious, but the advantage of flattening everything into one universal representation is that it's a very simple API for opclass authors, that puts control into the hands of the core nbtree code, where it belongs. For text, say, you can generate fictitious minimal separator keys with suffix truncation, that really are as short as possible, down to level of individual bits. If you tried to do this with the original text representation, you'd have to worry about the fact that that's probably not going to even be valid UTF-8, and that encoding aware truncation is needed, etc. You'd definitely have to "double check" that the truncated key was greater than the left half and less than the right half, just in case you didn't end up with a valid separator due to the vagaries of the collation rules. That's the kind of complexity that scales poorly, because the complexity cannot be isolated. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
