Re: Range Types and extensions - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Range Types and extensions
Date
Msg-id 8739jnjflg.fsf@hi-media-techno.com
Whole thread Raw
In response to Range Types and extensions  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Range Types and extensions
Re: Range Types and extensions
List pgsql-hackers
Jeff Davis <pgsql@j-davis.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 defaultb. contribs, not shipped by default, maintained by core hackersc. examples,
includedin the source code only, maintained as contribsd. “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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Bug in XPATH() if expression returns a scalar value