Re: Range Types

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