Re: Custom tuplesorts for extensions

Поиск
Список
Период
Сортировка
От Pavel Borisov
Тема Re: Custom tuplesorts for extensions
Дата
Msg-id CALT9ZEHjgO_r2cFr35=u9xZa6Ji2e7oVfSEBRBj0Gc+tJjTxSg@mail.gmail.com
обсуждение исходный текст
Ответ на Custom tuplesorts for extensions  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: Custom tuplesorts for extensions  (Maxim Orlov <orlovmg@gmail.com>)
Re: Custom tuplesorts for extensions  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-hackers
Some PostgreSQL extensions need to sort their pieces of data. Then it
worth to re-use our tuplesort. But despite our tuplesort having
extensibility, it's hidden inside tuplesort.c. There are at least a
couple of examples of how extensions deal with that.

1. RUM table access method: https://github.com/postgrespro/rum
RUM repository contains a copy of tuplesort.c for each major
PostgreSQL release. A reliable solution, but this is not how things
are intended to work, right?
2. OrioleDB table access method: https://github.com/orioledb/orioledb
OrioleDB runs on patches PostgreSQL. It contains a patch, which just
exposes all the guts of tuplesort.c to the tuplesort.h
https://github.com/orioledb/postgres/commit/d42755f52c

I think we need a proper way to let extension re-use our core
tuplesort facility. The attached patchset is intended to do this the
right way. Patches don't revise all the comments and lack code
beautification. The intention behind publishing this revision is to
verify the direction and get some feedback for further work.

I still have one doubt about the thing: the compatibility with previous PG versions requires me to support code paths that I already added into RUM extension. I won't be able to drop it from extension for quite long time in the future. It could be avoided if we  backpatch this, which seems doubtful to me provided the volume of code changes.

If we just change this thing since say v16 this will only help to extensions that doesn't support earlier PG versions. I still consider the change beneficial but wonder do you have some view on how should it be managed in existing extensions to benefit them?

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com

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

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: some aspects of our qsort might not be ideal
Следующее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: Fix instability in subscription regression test