Hi,
Jeff Davis <pgsql@j-davis.com> writes:
> * Should pg_range reference the btree opclass or the compare function
> directly?
I would say yes. We use the btree opclass in other similar situations.
> * Should subtype_cmp default to the default btree opclass's compare
> function?
My vote is yes too.
> * Right now only superusers can define a range type. Should we open it
> up to normal users?
Is there any reason to restrict who's get to use the feature? I don't
see any…
> * Should the SQL (inlinable) function "length", which relies on
> polymorphic "-", be immutable, strict, or volatile?
I would think stable: polymorphic means that the function
implementing the "-" operator depends on the argument. I don't recall
that it depends on them in a volatile way… except if you change the
operator definition, which is possible to do (so not immutable).
> * Later we might consider whether we should include btree_gist in
> core, to make range types more useful with exclusion constraints
> out-of-the-box. This should be left for later, I'm just including this
> for the archives so it doesn't get lost.
I would expect the extension to have something to offer here.
~=# create extension btree_gist with schema pg_catalog; CREATE EXTENSION
Now you can act as if it were part of core. Including not being able to
ALTER EXTENSION SET SCHEMA (cannot remove dependency on schema
pg_catalog because it is a system object), but maybe the recent changes
that Tom done on the usage of DEPENDENCY_INTERNAL in the extension patch
will open that again.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
