On Mon, 2011-02-07 at 13:33 +0100, Dimitri Fontaine wrote:
> 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.
Ok, but what should the parameter to CREATE TYPE ... AS RANGE be then?
CREATE TYPE foo AS RANGE ( SUBTYPE = ... SUBTYPE_BTREE_OPERATOR_CLASS = ...
);
is a little verbose. Ideas?
> Is there any reason to restrict who's get to use the feature? I don't
> see any…
Mostly just paranoia. If they define a strange canonical function, maybe
that would cause a problem. Then again, they would have to define that
in C to cause a problem anyway. I'll leave it as superuser-only for now,
and see if anyone else raises potential problems.
> > * 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).
I was concerned about someone defining "-" with a stable or volatile
function as the definition. I'm not sure if that is a reasonable concern
or not.
> > * 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.
Yes. With extensions and PGXN, I would hope that installing btree_gist
would not be much of a problem. However, I eventually intend to submit
features like "RANGE KEY", a language extension that would need
something like btree_gist to work very well at all. Technically
btree_gist is not required, but in practice it is necessary to use
ranges and exclusion constraints together effectively.
Regards,Jeff Davis