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?
Re: Do we really want to migrate plproxy and citext into PG core distribution? |
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: