| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | btree_gist into core? |
| Date: | 2022-01-19 08:30:11 |
| Message-ID: | 5fd19680-c0db-e9ea-eae6-971a369b4233@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
To use exclusion constraints in practice, you often need to install the
btree_gist extension, so that you can combine for example a range type
check and normal scalar key columns into one constraint.
The currently proposed "application time" feature [0] (also known more
generally as temporal database) is in many ways essentially an
SQL-syntax wrapper around typical use cases involving ranges,
multiranges, and exclusion constraints. As such, it also needs
btree_gist installed in most (all?) cases. I have argued over in that
thread that it would be weird to have a built-in SQL feature that relied
on an extension to work at all. So I think the way forward would be to
move btree_gist into core, and I'm starting this new thread here to give
this topic a bit more attention.
So, first of all, would people agree with this course of action?
I don't have a lot of experience with this module, so I don't know if
there are any lingering concerns about whether it is mature enough as a
built-in feature.
If we were to do it, then additional discussions could be had about how
to arrange the code. I suspect we wouldn't just want to copy the files
as is under utils/adt/, since that's a lot of files.
There are also of course questions about how to smoothly arrange
upgrades from extensions to the built-in situations.
Thoughts?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2022-01-19 08:30:59 | Re: generic plans and "initial" pruning |
| Previous Message | Julien Rouhaud | 2022-01-19 08:30:01 | Re: [PATCH] Add reloption for views to enable RLS |