Re: Range Types

Hi,

Jeff Davis <pgsql(at)j-davis(dot)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