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

From Bruce Momjian
Subject Re: advisory locks and permissions
Date
Msg-id 200609221909.k8MJ9QM12380@momjian.us
Whole thread Raw
In response to Re: advisory locks and permissions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: advisory locks and permissions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> I'm disinclined to change that, because it would probably break existing
> >> client-side code for little gain.
> 
> > I think clarity suggests we should make the heading match the feature,
> > i.e call it "advisory" rather than "userlock".   We changed the API, I
> > don't see why keeping the heading makes sense. 
> 
> (a) we changed a *different* part of the API; I don't see how that
> licenses us to whack around anything that's marginally related.
> 
> (b) we put up that pgfoundry module so that there would be a backward
> compatible solution.  Won't be very backward compatible if the locks
> look different in pg_locks.

But is anyone going to know what userlocks is in 1-2 years?  We have few
people using /contrib/userlocks, but in the future, I bet we have a lot
more people using advisory locks, and being confused.

--  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: Stephen Frost
Date:
Subject: Re: advisory locks and permissions
Next
From: Tom Lane
Date:
Subject: Re: Fwd: Is the fsync() fake on FreeBSD6.1?