Re: Do we really want to migrate plproxy and citext into PG core distribution? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Do we really want to migrate plproxy and citext into PG core distribution?
Date
Msg-id 4884EF67.1070608@dunslane.net
Whole thread Raw
In response to Do we really want to migrate plproxy and citext into PG core distribution?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Do we really want to migrate plproxy and citext into PG core distribution?  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers

Tom Lane wrote:
> The current commitfest queue has two entries that propose to migrate
> existing pgfoundry projects (or improved versions thereof) into our
> core distribution.  The more I think about this the less happy I am
> with it.  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.  From a features
> point of view, yeah they're cool, but there are scads of cool things
> out there.  From a project-management point of view, it's insanity
> to set a presumption that pgfoundry is just a proving ground for code
> that should eventually get into core once it's mature enough or popular
> enough or whatever. 


I think there is a case to say that modules that are sufficiently 
popular have a case to be in core.

That's not necessarily a large number, but there might well be a case 
for citext at least to be among the number at some stage. Surely a case 
insensitive text type has more general use than, say, the seg module.



>  We *have to* encourage the development of a cloud
> of subprojects around the core, or core will eventually collapse of
> its own weight.  We have not got the manpower to deal with an
> ever-inflating collection of allegedly "core" code.  If anything,
> we ought to be working to push more stuff out of the core distro so
> that we can focus on the functionality that has to be there.
>   


When we can get the much discussed module infrastructure that will make 
more sense. We will still need to keep enough modules to make sure that 
the infrastructure is working. In general I feel that the number of 
modules we have in core is about right. Maybe a small number should be 
pushed out.

> So my feeling is that we should not accept either of these patches.
>
> Now, there is some value in submitting the code for review --- certainly
> citext is a whole lot better than it was a few weeks ago.  I think it
> would be a good idea to be open to reviewing pgfoundry code with the
> same standards we'd use if we were going to integrate it.  Perhaps
> commitfest is not the right venue for that, though, if only because
> of the possibility of confusion over what's supposed to happen.
>
> Comments?
>
>     


If we don't have enough resources to maintain them do we have enough to review them?



I was going to write some stuff about citext anyway. Quite apart from 
the above considerations I'm still a bit concerned about its performance 
characteristics. And I'm not sure we really want all the baggage that 
David is proposing to bring along with it. Is it an advance to force the 
regex_replace "i" flag for such a type? I can imagine cases where I 
might want it to sort insensitively, but be able to do case sensitive 
regex ops on it. It's not as if the user can't supply the flag. So right 
now I don't think citext should be included, because there are still 
issues to sort out, if for no other reason.


cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution?
Next
From: "Marko Kreen"
Date:
Subject: Re: [patch] plproxy v2