Re: pg_locks needs a facelift
От | Merlin Moncure |
---|---|
Тема | Re: pg_locks needs a facelift |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3415C274A@Herge.rcsinc.local обсуждение исходный текст |
Ответ на | pg_locks needs a facelift (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom wrote: > Don't worry, I'll veto any immediate removal of functionality ;-) > The correct way to handle this is to add some better userlock > functionality and deprecate what's there. We can remove the crufty > stuff in a release or three after it's been officially deprecated > ... but there is no reason to remove it immediately. It won't conflict > with a better version, just exist alongside. hm. how about this: leave the userlock contrib module completely alone and call them 'application locks' (what is the 'user' in userlock?). Basic points: 1. tweak sources replacing 'user' with 'application' in various places 2. application locks interface is in core project and properly documented 3. provide 64 bit (or more?) lock space...oid plays no direct role 4. deprecate userlock module but leave it otherwise unchanged. 5. add string based locking to the interface? Merlin
В списке pgsql-hackers по дате отправления: