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 into PG core distribution? |
Date: | 2008-07-24 19:31:52 |
Message-ID: | 1216927912.7001.72.camel@huvostro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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 ;)
-----------------
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-24 20:30:09 | Re: [PATCHES] GIN improvements |
Previous Message | Teodor Sigaev | 2008-07-24 19:24:11 | Re: [PATCHES] GIN improvements |