| 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: | Whole Thread | Raw Message | 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 |