On Tue, Jan 25, 2005 at 08:19:05AM -0500, Merlin Moncure wrote:
> > > [ 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.
I believe if there was a way to specify in userlock what table you were
working with that the current 48 bit lock size should be OK for almost
any situation. With the current scheme you could have locks on 65k
tables, any of which could have up to 2^32 rows (has anyone actually
ever exceeded 2^32 rows?). Granted, it's not perfect, but it's better
than what we have now.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"