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?


[0]: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mdhcy4_qq0+noc...@mail.gmail.com


Reply via email to