Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 2008-07-21 at 15:43 -0400, Tom Lane wrote:
>> From a maintenance point of view there seems little need
>> for either project to get integrated: they don't appear to have much
>> of any code that is tightly tied to backend innards.
> This is a slightly circular argument. They have had to be written with
> no linkage to core to allow them to be created outside of it.
True, but in the form in which they are currently presented there is no
(technical) reason to integrate them: no new capability would be
provided thereby. Contrast with, say, text search, which we integrated
mainly because we could provide easier configuration and a better
dump/restore experience than the contrib module provided.
> In both these cases, I can see that the capability could be provided in
> a different way and benefit from tighter integration.
Perhaps. I think a lot of the dump/restore issue could be solved
generically if we had better "module" support ... but there's no need
to go over that turf again right now.
In the case of citext, I think an "integrated" solution would involve
some way of creating case-insensitive collations, which would certainly
be cool but it requires a whole lot of infrastructure we don't have yet.
And it wouldn't look even a little bit like the present citext, nor
be upward compatible with it.
In the case of plproxy, I think an integrated solution is pronounced
"SQL-MED", and likewise plproxy in its present form doesn't move us
toward that goal.
An important point here is that acceptance of a feature into core (or
even contrib) puts us on the hook to worry about upward compatibility
for it, maybe not forever but for a long time into the future.
I don't think I want to buy into that for either of these as presently
constituted --- they don't match up with what I think the long-term
goals ought to be in these areas.
regards, tom lane
