Re: Do we really want to migrate plproxy and citext into PG core distribution?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution?
Date: 2008-07-21 20:19:51
Message-ID: 4884EF67.1070608@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Kreen 2008-07-21 20:21:50 Re: [patch] plproxy v2
Previous Message Tom Lane 2008-07-21 20:18:10 Re: Do we really want to migrate plproxy and citext into PG core distribution?