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.
> 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
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
> 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
> 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
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 Lane||Date: 2008-07-24 20:30:09|
|Subject: Re: [PATCHES] GIN improvements |
|Previous:||From: Teodor Sigaev||Date: 2008-07-24 19:24:11|
|Subject: Re: [PATCHES] GIN improvements|