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

On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
> On Thu, 2008-07-24 at 18:38 +0300, Hannu Krosing wrote:
> > On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
> > > 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.
>
> > I'm pretty sure that there is no general golden-bullet solution for
> > achieving this, and thus I can't see how pl/proxy can conflict with any
> > "long-term goals" in "these areas", for any value of "these areas".
> >
> > pl/proxy also has some other possible uses, like doing callbacks in
> > independent transactions, simple remote calls, simple RO load balancing,
> > etc.
>
> Hannu,
>
> These are all excellent points but I think the real problem here is:
>
> There is nothing that requires pl/proxy to be in core.

AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to be
in core either.

Actually, I think that being an independent language / postgresql
extension tool, pl/proxy is _more_ fit to be in core than external
language adapters.

And it would be nice, if some well-maintained sample language (pl/sh or
even pl/dummy) which serves as a sample of latest ways to make use of
pl/function support in core pg code would be included in core as well.

with some slight restructuring (separation of pl-clue and actrual
cacheing/execution) pl/proxy could serve this space as well

> Everyone already agrees pl/proxy is very cool technology for PostgreSQL.
>
> I used to make a lot of arguments about pushing things into core, I was
> big fanboy of getting Tsearch2 into core. Looking back and getting older
> and wiser (no laughing :P) I realize that its almost kind of silly to
> keep pushing this stuff into core.

Not silly at all.

Tsearch in core seems a wise choice, as well as _some_ implementation of
multiple locales.

> Lots of people talk about legitimacy of the package or some sort of
> artificial endorsement that gets created by being in core. Some of it is
> personal, it is a big feeling of pride to have a piece of code accepted
> to core.

Usually it is also a way of getting the _core_ better/more functional.

> It is also a way to beef up the resume and yes generally a way
> to deal with more ignorant hosting shops that won't install external
> modules.
>
> However this is not a core problem. It is not a hacker problem. It is
> and education and advocacy problem. We don't need pl/proxy in core. What
> pl/proxy needs is a solid project of its own, with good documentation,
> and community members.

As mentioned in another mail, we don't _need_ other pl-s (except maybe
pl/pgsql) to be in core either.

And it is an additional bonus for consultants, if we keep some of the
best parts separate ;)

-----------------
Hannu

PS. Thinking more of it, I don't even understand, what it means for a
PL to be "in core" ;)

Are they are under src/pl just for the reason that there is not
contrib/pl ?

Does pushing something into core give impression of trying to get rid of
the responsibility of managing that piece of code ?

------------------
Hannu