RE: User locks code

> > If the licence becomes a problem I can easily change it,
> > but I prefer the GPL if possible.
> 
> We just wanted to make sure the backend changes were not
> under the GPL.

No, Bruce - backend part of code is useless without interface
functions and I wonder doesn't GPL-ed interface implementation
prevent using of user-locks in *commercial* applications.
For example, one could use user-locks for processing incoming
orders by multiple operators:
select * from orders where user_lock(orders.oid) = 1 LIMIT 1
- so each operator would lock one order for processing and
operators wouldn't block each other. So, could such
application be commercial with current licence of
user_lock()? (Sorry, I'm not licence guru.)

DISCLAIMER (to avoid ungrounded rumors -:))
I have no plans to use user-locks in applications
of *any* kind (free/commercial). It's just matter of
principle - anything in/from backend code maybe used
for any purposes, - that's nature of our licence.

DISCLAIMER II (to avoid ungrounded rumors in future -:))
I would be interested in using proposed "key-locking"
in some particular commercial application but this
feature is not "must have" for that application -
for my purposes it's enough:

----------------------------------------------------------
LOCKTAG tag;
tag.relId = XactLockTableId;
tag.dbId = _tableId_;
// tag.dbId = InvalidOid is used in XactLockTableInsert
// and no way to use valid OID for XactLock purposes,
// so no problem
tag.objId.xid = _user_key_;
----------------------------------------------------------

- but I like standard solutions more -:)
(BTW, key-locking was requested by others a long ago.)

Vadim