I have committed the pg_range patch. On 19.01.26 19:33, Paul A Jungwirth wrote:
Do we want a regress test in rangetypes.sql to confirm that these are set correctly (especially for user-defined types)? I checked manually after `make installcheck`, and they look fine, but should it be in our test suite?
I think the existing tests do that, since type_sanity runs after the rangetypes test.
Here is another thought I had: As we've talked about in the application-time threads, I would like temporal features to be extensible enough to support user-defined types. We almost achieve that, but we need something like a "type support function". For primary key and unique constraints, we need a way to reject invalid values like empty ranges. For foreign keys we need an intersect operator (which is not currently in pg_amop, since it is neither for search nor ordering, and isn't involved in indexes anyway). And for UPDATE/DELETE FOR PORTION OF we need a foo_minus_multi to compute the "temporal leftovers". We could also ask for a constructor function, to build the targeted portion from the FROM/TO bounds. This is not strictly necessary, since we also have the FOR PORTION OF valid_at (...) syntax (which is used by multiranges). But it's something that would be nice to offer. In that case range types would not need these extra columns in pg_range. But recording the constructor oids in pg_range still has inherent value, and doing it now doesn't *prevent* us from later adding a facility to get a constructor function for FOR PORTION OF bounds. So I don't think there is any downside to recording them here.
Right, that sounds like a future project.
