Skip site navigation (1) Skip section navigation (2)

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

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Do we really want to migrate plproxy and citext intoPG core distribution?
Date: 2008-07-24 19:31:52
Message-ID: 1216927912.7001.72.camel@huvostro (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 ;)


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 ?


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-07-24 20:30:09
Subject: Re: [PATCHES] GIN improvements
Previous:From: Teodor SigaevDate: 2008-07-24 19:24:11
Subject: Re: [PATCHES] GIN improvements

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group