pg_uuid_t support in contrib/btree_gist

Поиск
Список
Период
Сортировка
От Jarred Ward
Тема pg_uuid_t support in contrib/btree_gist
Дата
Msg-id CAMLLTyYmqCmrTy4VLfxfW_xgCeoPAgVtUEwkxvZ5EfRQddXmVg@mail.gmail.com
обсуждение исходный текст
Ответы Re: pg_uuid_t support in contrib/btree_gist  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I'd like to add uuid support to contrib/btree_gist.

Proposal:

* Add `contrib/btree_gist/btree_uuid.c' with implementation based on gbtree_ninfo type description
* Modify `contrib/btree_gist/btree_utils_num.c' to support pg_uuid_t
* Modify `contrib/btree_gist/btree_gist.h' to add gbt_t_uuid type
* Add `contrib/btree_gist/btree_gist--1.2.sql' with gist_uuid_ops
* Modify `Makefile' to build btree_uuid
* Modify `contrib/btree_gist/btree_gist.control' to set default_version to 1.2
* Regression tests
* I've probably missed something, but that's the basic idea

Question:

pg_uuid_t is an opaque type in `src/include/utils/uuid.h'. To put this type in a struct for both a new uuidKEY and the gbtree_ninfo type description support we need the implementation of the struct that is currently hidden in `src/backend/utils/adt/uuid.c'.

We could get around this by using gbtree_vinfo type description for uuid, but this is not a var type. That smells a little to me.

Is modifying `src/include/utils/uuid.h' to leak the implementation details of pg_uuid_t in `src/backend/utils/adt/uuid.c' an option? It seems pretty drastic to make that change just for contrib/btree_gist, but the 16-byte char[] representation seems fairly standard to me.

I don't know why this would be needed at some point in the future, but another possible impl could be a hi/lo int64 to represent the uuid type (like java), so leaking the implementation details would potentially add a btree_gist dependency to ever doing this in the future.

A third option is to have our own impl of pg_uuid_t or something similar in btree_gist. Having two independent implementations of pg_uuid_t in postgres and btree_gist smells even worse and opens us up to dependency issues (that may very well be caught by the regression tests).

The answer is not obvious to me how to proceed on this.

(I'm a first-time poster so please correct any procedures or etiquette I'm missing)

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: BRIN index and aborted transaction
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: object_classes array is broken, again