Merlin Moncure wrote: > On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: > > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match