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

Hi hackers

Just my non hacker view on the pl/proxy matter.

>From FAQ:
PL/Proxy is compact language for remote calls between PostgreSQL databases.

Why we submitted pl/proxy into core at all?
1. Current core distribution contains dblink which sucks both usability wise
and security wise but being part of core distribution will be first thing
people are going to try out. We wanted to save people losing couple of days
trying out dblink before looking for other alternatives like it happend with
us.
2. Various languages are part of core distribution and pl/proxy by adding
possibility to call remotely procedures created with these languages seems
to be logical extension to PostgreSQL in general. And it makes it essential
for pl/proxy to stay compatible with all the developments in function
calling syntax.
3. And last but not least to make it easier to use for whoever who might
need to do remote procedure calls between PostgreSQL servers.

So i rephrase your question:
Would capability to do remote procedure calls useful addition to PostgreSQL
feature set?

In my experience when organization grows out of one database on one server
remote calls are needed quite soon.

About citext. Skype is using various hacks and workarounds because there was
no such type in PostgreSQL and i understand others also. To me it seems to
be choice between couple of developers doing it once and for all and
hundreds of developers inventing the wheel every day and not to mention
hours spent debugging over various layers of applications. It just shows how
hackers have totally different point of view on things from people who are
using the program:) But again i am just a manager and should be lower than
grass in hackers list :)

regards.
Asko
skype: askoja

PS: I am sorry for this reply coming so late didn't want to spoil my
vacation :)

On Mon, Jul 21, 2008 at 10:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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. 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.
>
> 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?
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>