Hi, Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
