Re: Do we really want to migrate plproxy and citext into PG core distribution? - Mailing list pgsql-hackers

From Asko Oja
Subject Re: Do we really want to migrate plproxy and citext into PG core distribution?
Date
Msg-id ecd779860807280811l44ff7428i2942099c51d6e23f@mail.gmail.com
Whole thread Raw
In response to Do we really want to migrate plproxy and citext into PG core distribution?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Do we really want to migrate plproxy and citext into PG core distribution?  (Andrew Dunstan <andrew@dunslane.net>)
Re: Do we really want to migrate plproxy and citext into PG core distribution?  ("Marko Kreen" <markokr@gmail.com>)
List pgsql-hackers
<div dir="ltr">Hi hackers<br /><br />Just my non hacker view on the pl/proxy matter.<br /><br /> From FAQ:<br />
PL/Proxyis compact language for remote calls between PostgreSQL databases.  <br /><br /> Why we submitted pl/proxy into
coreat all?<br /> 1. Current core distribution contains dblink which sucks both usability wise and security wise but
beingpart of core distribution will be first thing people are going to try out. We wanted to save people losing couple
ofdays trying out dblink before looking for other alternatives like it happend with us.<br /> 2. Various languages are
partof core distribution and pl/proxy by adding possibility to call remotely procedures created with these languages
seemsto be logical extension to PostgreSQL in general. And it makes it essential for pl/proxy to stay compatible with
allthe developments in function calling syntax.<br />3. And last but not least to make it easier to use for whoever who
mightneed to do remote procedure calls between PostgreSQL servers.<br /><br /> So i rephrase your question:<br /> Would
capabilityto do remote procedure calls useful addition to PostgreSQL feature set?<br /><br /> In my experience when
organizationgrows out of one database on one server remote calls are needed quite soon. <br /><br />About citext. Skype
isusing various hacks and workarounds because there was no such type in PostgreSQL and i understand others also. To me
itseems to be choice between couple of developers doing it once and for all and hundreds of developers inventing the
wheelevery day and not to mention hours spent debugging over various layers of applications. It just shows how hackers
havetotally different point of view on things from people who are using the program:)  But again i am just a manager
andshould be lower than grass in hackers list :)<br /><br /> regards.<br /> Asko<br /> skype: askoja<br /><br /> PS: I
amsorry for this reply coming so late didn't want to spoil my vacation :)<br /><br /><div class="gmail_quote">On Mon,
Jul21, 2008 at 10:43 PM, Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The current commitfest
queuehas two entries that propose to migrate<br /> existing pgfoundry projects (or improved versions thereof) into
our<br/> core distribution.  The more I think about this the less happy I am<br /> with it.  From a maintenance point
ofview there seems little need<br /> for either project to get integrated: they don't appear to have much<br /> of any
codethat is tightly tied to backend innards.  From a features<br /> point of view, yeah they're cool, but there are
scadsof cool things<br /> out there.  From a project-management point of view, it's insanity<br /> to set a presumption
thatpgfoundry is just a proving ground for code<br /> that should eventually get into core once it's mature enough or
popular<br/> enough or whatever.  We *have to* encourage the development of a cloud<br /> of subprojects around the
core,or core will eventually collapse of<br /> its own weight.  We have not got the manpower to deal with an<br />
ever-inflatingcollection of allegedly "core" code.  If anything,<br /> we ought to be working to push more stuff out of
thecore distro so<br /> that we can focus on the functionality that has to be there.<br /><br /> So my feeling is that
weshould not accept either of these patches.<br /><br /> Now, there is some value in submitting the code for review ---
certainly<br/> citext is a whole lot better than it was a few weeks ago.  I think it<br /> would be a good idea to be
opento reviewing pgfoundry code with the<br /> same standards we'd use if we were going to integrate it.  Perhaps<br />
commitfestis not the right venue for that, though, if only because<br /> of the possibility of confusion over what's
supposedto happen.<br /><br /> Comments?<br /><br />                        regards, tom lane<br /><font
color="#888888"><br/> --<br /> Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your
subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></font></blockquote></div><br /></div> 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WITH RECUSIVE patches 0723
Next
From: Andrew Gierth
Date:
Subject: Re: WITH RECUSIVE patches 0723