Re: advisory locks and permissions - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: advisory locks and permissions
Date
Msg-id 200609222036.k8MKaLd20073@momjian.us
Whole thread Raw
In response to Re: advisory locks and permissions  ("Merlin Moncure" <mmoncure@gmail.com>)
Responses Re: advisory locks and permissions
List 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 by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: advisory locks and permissions
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: initdb ignores invalid locale names