> > [ yawn... ] Create a table with a "name" column, put some rows in
it,
> > lock the rows.
>
> What would guarantee that the OIDs of those rows don't conflict with
> some other OIDs in the system?
>
> BTW, this becomes a real issue if you're trying to write code that is
> meant to be incorporated into other PostgreSQL applications, which
might
> also be using user_lock. Having a text-based means to identify locks
> greatly reduces the odds of conflicting with a userlock being used by
an
> existing application.
I prefer sequences to OIDs in virtually every aspect, including this
one. However, it would be nice to have system generated unique tuple
identifier. There isn't one currently that would fit in the userlock
restriction of 48 bits. Any identifier derived from system columns
probably would take 96-128 bits (for example ctid/tableoid combo).
IMO, the current behavior is ok, meaning I don't necessarily feel that
there should be a candidate system key to use for them. However I would
discourage the use of OIDs with them.
Merlin