Re: advisory locks and permissions
От | Bruce Momjian |
---|---|
Тема | Re: advisory locks and permissions |
Дата | |
Msg-id | 200609222036.k8MKaLd20073@momjian.us обсуждение исходный текст |
Ответ на | Re: advisory locks and permissions ("Merlin Moncure" <mmoncure@gmail.com>) |
Ответы |
Re: advisory locks and permissions
|
Список | pgsql-hackers |
Merlin Moncure wrote: > On 9/22/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > > I don't see the column rename as an > > > API change issue. > > > > How can you possibly claim it's not an API change? > > > > i dunno, i agree with bruce here. we are just changing the output of > pg_locks a bit reflecting the change in moving contrib to core. > nobody cares about the literal output of pg_locks for userlocks except > the old contrib users. compatiblity could be supplied in the pgfoundry > module for this as well. i say to leave the lock tables alone and > change to 'advsiory'. it just seems odd the way it is. Agreed. I just don't imagine many current user applications referencing userlocks, and I do imagine confusion in the future by users using the new API which call them "advisory". I guess it is a compatibility change, but weighing compatibility against clarity, I am leaning toward clarity. I assume it is this line that would be changed: _("user lock [%u,%u,%u,%u]"), By my reading of that, that string is language-local, so anyone trying to parse that directly is going to have a larger problem than our renaming it for 8.2. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: