From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: userlock changes for 8.1/8.2 |
Date: | 2005-01-25 20:02:45 |
Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3412A75E3@Herge.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tgl wrote:
> [ shrug... ] Since userlocks are only advisory, a non-cooperating
> client can break anything in sight anyway. I don't find the above
> argument convincing. But in any case, you can use an OID or serial
> sequence identifier if you prefer that to CTID. They're just integers
> and it's really up to the user application to define the
interpretation
> of a userlock tag.
Right. My point is that use of CTIDs just too easy to screw up from the
user's perspective, because they change with updates. I was briefly
toying with a 'auto lock' mode which built the lock from ctid +
tableoid.
So, I'd suggest discouraging the use of ctid, just like the use of OIDs
is discouraged (in fact there is already a disclaimer about using ctid
as a logical identifier in the docs). Certainly we can't provide a
tighter integration between the user locks and the system columns via
extensions to the grammar, etc.
So it becomes a documentation issue.
Merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2005-01-25 20:06:33 | Re: [HACKERS] userlock changes for 8.1/8.2 |
Previous Message | Tom Lane | 2005-01-25 19:09:12 | Re: userlock changes for 8.1/8.2 |