Greetings,
I'd like to propose a potential patch, and wanted to get preliminary
feedback on it before I started looking into the design.
Summary: Add a string key space to the advisory lock functionality.
Rationale:
Right now, the key spaces (the range of unique values that can be used
as identity) for advisory locks are either a bigint or two ints. This
is, of course, technically more than one could imaginably need in any
application. The difficulty arises when the number of potential
advisory locks is related to rows in one or more tables.
For example, suppose one wanted to use advisory locks to signal that a
queue entry is being processed, and entries in that queue have a
primary key that's also a bigint. There's no problem; the advisory
lock id is the primary key for the row.
And, then, one wants to use an advisory lock to signal that a
particular record in another table is being processed in a long-term
process. One has a series of unappealing alternatives at that point,
mostly involving encoding a table ID and the primary key of a record
into the 64 bit number, or just hoping that the primary key doesn't
overflow an int, and using the 2 x int form.
API Changes:
Overloading the various advisory lock functions to take a suitable
string type (varchar(64)?) in addition to the bigint / 2 x int
variations. As with the bigint / 2 x int forms, this string namespace
would be disjoint from the other key spaces.
Thanks in advance for any comments.
--
-- Christophe Pettus xof@thebuild.com
