SEO

Bruce,

After some delay with server issues, I've loaded these contrib modules. Since
I'm not hip to the magic required to remove a directory safely in CVS, please
do it for me?

Migrated to pgFoundry:
adddepends (Greg)
dbmirror (Steve Singer)
dbase --> dbf2pg
fulltextindex --> simplefti
mac (LER) --> mac-manufacturer
userlock (Merlin)

Please also kill the following two contrib directories, because despite an
impassioned plea by Robert Treat, they appear to not have any users (at least
nobody responded to posts on PWN or -hackers)
tips
mSQL-interface

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On 2006-09-05, Josh Berkus <josh@agliodbs.com> wrote:
> Migrated to pgFoundry:
[...]
> userlock (Merlin)

Userlock needs to go into core, not get removed; this was discussed in a
previous "let's clean up contrib/" thread. If it's not going into core
in 8.2 then it needs to stay in contrib.

People then didn't seem receptive to my suggestion that the existing
userlock code was non-copyrightable (on the grounds of being pure
interface), but that difficulty no longer exists now that Abhijit has
posted his clean-room rewrite (look for "otherlock" in -patches).
Perhaps he would be prepared to turn that into a patch against the core...

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

Josh Berkus <josh@agliodbs.com> writes:
> Migrated to pgFoundry:
> adddepends (Greg)
> dbmirror (Steve Singer)
> dbase --> dbf2pg
> fulltextindex --> simplefti
> mac (LER) --> mac-manufacturer
> userlock (Merlin)

> Please also kill the following two contrib directories, because despite an
> impassioned plea by Robert Treat, they appear to not have any users (at least
> nobody responded to posts on PWN or -hackers)
> tips
> mSQL-interface

Checking my copy of the "hit list", I thought we'd agreed to migrate
contrib/oracle as well.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Andrew - Supernews <andrew+nonews@supernews.com> writes:
> Userlock needs to go into core, not get removed; this was discussed in a
> previous "let's clean up contrib/" thread.

Something like it ought to go into core, but personally I'd opt for
taking the opportunity to redesign the API, which was a bit crufty to
begin with. That would eliminate all question of whether the clean room
was clean enough.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

At 2006-09-05 10:23:19 -0400, tgl@sss.pgh.pa.us wrote:
>
> Something like it ought to go into core, but personally I'd opt for
> taking the opportunity to redesign the API, which was a bit crufty to
> begin with.

I'm happy to do the work right away (not that there's much) if someone
suggests a better API. (I don't personally have a need for user-level
locks, and if I did, I'd be happy with just user_lock/user_unlock. So
if anyone has a more specific idea, I'm all ears.)

> That would eliminate all question of whether the clean room was
> clean enough.

It was really, really clean! Honest! :-)

-- ams

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Andrew Dunstan <andrew@dunslane.net> writes:
> It's a pity we didn't have Abhijit's patch 6 weeks ago.

Well, now that we have it, the question is whether we want to do
anything with it. One problem is it lacks documentation.

However, as I said, I'd really rather choose a new API altogether. The
main thing that seems to be lacking is a way to wait for a lock, rather
than having only the equivalent of ConditionalLockAcquire. Also I don't
much like exposing a LOCKMODE directly to user code --- to use
user_lock() or user_unlock() you have to put magic numbers into your SQL
code and hope nobody reassigns the C enum values in future releases.
I'd be inclined to just expose the notions of "share" and "exclusive"
lock and make these separate functions instead of magic numbers.

And then there's the question of what to expose in the way of lock
identifier options. What we've got now is "two int4's or an OID"
which seems a bit random, not to mention that the key space overlaps
in an undocumented fashion. Possibly we could offer OID, int8, or
two int4s, and modify the code to set locktag_field4 to distinguish
these cases so that the key spaces are independent.

I have no opinions about function names, except that I'd suggest
choosing names based around "advisory lock" instead of "user lock".
Advisory locks are a standard concept and so that terminology
already tells people something ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:
> Andrew - Supernews <andrew+nonews@supernews.com> writes:
>
>> Userlock needs to go into core, not get removed; this was discussed in a
>> previous "let's clean up contrib/" thread.
>>
>
> Something like it ought to go into core, but personally I'd opt for
> taking the opportunity to redesign the API, which was a bit crufty to
> begin with. That would eliminate all question of whether the clean room
> was clean enough.
>
>
>

It seems odd to remove the module from contrib for 8.2 and then put a
replacement in core for 8.3. I guess we could signal our intentions in
the release notes.

It's a pity we didn't have Abhijit's patch 6 weeks ago.

cheers

andrew


---------------------------(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

Andrew,

> It seems odd to remove the module from contrib for 8.2 and then put a
> replacement in core for 8.3. I guess we could signal our intentions in
> the release notes.

The current code is GPL. It *has* to be removed.

--Josh

---------------------------(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

Josh Berkus <josh@agliodbs.com> writes:
>> 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.

Actually ... never mind that, it seems to have been done already.
Sorry for the noise.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On 2006-09-05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> It's a pity we didn't have Abhijit's patch 6 weeks ago.
>
> Well, now that we have it, the question is whether we want to do
> anything with it. One problem is it lacks documentation.
>
> However, as I said, I'd really rather choose a new API altogether.

What about existing users?

> The main thing that seems to be lacking is a way to wait for a lock,

Is this a feature that people actually want or need?

Certainly exposing the lockmode as a magic number isn't ideal.

> And then there's the question of what to expose in the way of lock
> identifier options. What we've got now is "two int4's or an OID"
> which seems a bit random, not to mention that the key space overlaps
> in an undocumented fashion.

It is documented in the original README.user_locks.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services