Re: Range Types and extensions

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> I'd like to take another look at Range Types and whether part of it
> should be an extension. Some of these issues relate to extensions in
> general, not just range types.

That's a good question :)

I think the way things are going to be organised now is that we will
have core-blessed extensions: don't mix the mechanism and the policy.

> non-issue if we had a good type interface system (that works on
> polymorphic types) -- we could just have a built-in "range" interface,
> and the range extension could add "&&" as the range interface's overlaps
> operator for the type ANYRANGE.

That means that this is, IMHO, the right approach. Have core support
that enables user defined RANGE types with indexing and planner support,
etc, like we have OPERATOR CLASS and FAMILY and all the jazz.

And the useful stuff you need to have to benefit from that core support
would be an extension. It could be a core maintained extension, and it
could even get installed by default, so that all the users would need to
do is 'CREATE EXTENSION timeranges;', for example.

So, I see us getting those different kinds of extensions in the future:

a. core extensions, shipped by default
b. contribs, not shipped by default, maintained by core hackers
c. examples, included in the source code only, maintained as contribs
d. “trusted network” of extensions (pgdg, pgxn, debian, privates, etc)
e. external independent extensions, just as now

The other main difference between a core extension and a contrib will be
where it's documented. Greg Smith proposed a patch wherein he moved
some contribs to a new extension/ place, and had them auto installed.

I think the consensus is to instead add a new chapter (maybe between
current chapters 9. Functions and Operators and 10. Type Conversion) and
host “core extensions” docs there. The source code organisation is
controversial because technically not necessary. We have to keep the
work Greg did to keep those contribs shipped by default. Oh, and that
is on the 9.1 Open Items, right?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support