This is a discussion on Ding-dong, contrib is dead ... within the pgsql Hackers forums, part of the PostgreSQL category; --> On 2006-09-05, Josh Berkus <josh@agliodbs.com> wrote: > The current code is GPL. It *has* to be removed. Which is ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| On 2006-09-05, Josh Berkus <josh@agliodbs.com> wrote: > The current code is GPL. It *has* to be removed. Which is why Abhijit's version exists - it's intended to be a drop-in, BSD-licensed replacement for the current code. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services |
| |||
| Tom, > Checking my copy of the "hit list", I thought we'd agreed to migrate > contrib/oracle as well. Hmmm ... somehow that got dropped out of discussions early on, without any reason why. See the "more nuclear options" thread; oracle is nowhere on it. Will only take me 30 min to migrate, but we need to give people time to object ... and I need to check whether there's even any code in there that superceded orasysviews and orafce and oralink. Hey, everyone, if you have a reason for contrib/oracle not to migrate out to pgFoundry, speak up now! Or if you want to take the new project over, speak up too. --Josh Berkus ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
| |||
| On 9/5/06, Andrew - Supernews <andrew+nonews@supernews.com> wrote: > On 2006-09-05, Josh Berkus <josh@agliodbs.com> wrote: > > The current code is GPL. It *has* to be removed. > > Which is why Abhijit's version exists - it's intended to be a drop-in, > BSD-licensed replacement for the current code. does his patch include documentation? I can help with that if it isn't done. was it reviewed? merlin ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
| |||
| "Merlin Moncure" <mmoncure@gmail.com> writes: > I also agree with Andrew that pgfoundry is not a appropriate place for > userlocks. They should be properly documented with a cleaned up api. > I have no objection from them being removed from contrib in the short > term due to the gpl issue, although I am not sure how you can > copyright a function wrapper. Right, I see the pgfoundry project as just a backwards-compatibility thing for anyone who doesn't want to change their code. I'm happy to put some cleaned-up functions into core right now (ie, for 8.2) if someone will do the legwork to define and implement them. After further thought it occurs to me that having both OID and int8 keys might be a problem, in that it's not too clear which you'd get from a single-argument call. But we could offer just int8 and two-int4 signatures and rely on promoting OID to int8 if you need a lock on OID. So the function list might look like void pg_advisory_lock(int8) wait void pg_advisory_lock_shared(int8) wait bool pg_try_advisory_lock(int8) no wait bool pg_try_advisory_lock_shared(int8) no wait bool pg_advisory_unlock(int8) returns T if successful bool pg_advisory_unlock_shared(int8) returns T if successful plus all the above taking 2 int4's, plus void pg_advisory_unlock_all() Not wedded to these names at all... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq |
| |||
| On 2006-09-05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Right, I see the pgfoundry project as just a backwards-compatibility > thing for anyone who doesn't want to change their code. I'm happy to > put some cleaned-up functions into core right now (ie, for 8.2) if > someone will do the legwork to define and implement them. So you're prepared to violate the feature freeze to stick in a new API that nobody currently wants to _use_, while forcing existing users to resort to pgfoundry for a module that's been around for several major releases? -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services |
| |||
| On 2006-09-05, "Merlin Moncure" <mmoncure@gmail.com> wrote: > On 9/5/06, Andrew - Supernews <andrew+nonews@supernews.com> wrote: >> On 2006-09-05, Josh Berkus <josh@agliodbs.com> wrote: >> > The current code is GPL. It *has* to be removed. >> >> Which is why Abhijit's version exists - it's intended to be a drop-in, >> BSD-licensed replacement for the current code. > > does his patch include documentation? I can help with that if it isn't > done. was it reviewed? I don't think it has docs. The existing docs would be fine unless anyone thinks that those also have copyright problems. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services |
| |||
| Tom Lane wrote: > I'm happy to > put some cleaned-up functions into core right now (ie, for 8.2) if > someone will do the legwork to define and implement them. > > OK, who are you and what have you done with the real Tom Lane? cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq |
| |||
| Josh Berkus <josh@agliodbs.com> writes: > Merlin, >> well, I'm confused now. Tom said that cleaned up functions might be >> sneaked into 8.2, which is what prompted my question. > You're correct, he did. Tom? Well, it's not like we're done with forced initdb's for 8.2, so I don't particularly see the harm in adding a few more functions. I would be against writing something large and complicated at this point, but these functions are trivial (practically one-liners) and I don't think there's a lot of debate needed about the API. The biggest part of the work needed is to write the documentation --- but we'd have to do that for Abhijit's patch too, since the userlocks docs presumably fall under GPL along with the code. So basically I don't see the point of investing effort in a bug-compatible version of userlocks, when we can have something cleaner and suitable for the long run with not very much more effort. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster |
| |||
| Tom Lane wrote: > Checking my copy of the "hit list", I thought we'd agreed to migrate > contrib/oracle as well. It has already been removed because it is being actively maintained elsewhere. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend |
| ||||
| Merlin, > > > The current code is GPL. It *has* to be removed. > > > > Which is why Abhijit's version exists - it's intended to be a drop-in, > > BSD-licensed replacement for the current code. > > does his patch include documentation? I can help with that if it isn't > done. was it reviewed? No, and no. It's unfortunately too late for Abhijit's patch to make it into 8.2; it was't submitted until last week, I believe. So userlocks will be in pgFoundry for the next rev -- frankly, it should have been for 8.1 but I forgot it. For the 8.3 version, as Tom has indicated we may want to change the API somewhat anyway, so we'll want the pgFoundry version for backwards-compat. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match |