On 9/22/06, AgentM <[EMAIL PROTECTED]> wrote:
I would be more worried about accidental collisions between applications. The lock ranges will now need to be in their respective
i dont think this argument has merit because the lock is scoped to the current database. this would only be a problem if two applications used the same database...not likely. the old userlocks had 48 bits of lock space and now we have 64, im not complaining.
application's configuration file in case of collision with another app once developers really start using locks for IPC. Ideally, the user-level lock functions would take strings instead of integers and hash them appropriately, no? Otherwise, someone will end up maintaining a registry of lock numbers in use. LISTEN doesn't use integers.
application can translate the locks to strings via a very simple translation table. there is no downside to this besides a index lookup on a small table, which is more or less what the listen/notify does internally. advisory locks work off of the internal lock system which is an integer only system. the whole point is to get at these locks while bypassing the transaction system. you are suggesting something which does not fit into the current lock system. merlin ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
