Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> (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.
>
> The reason they're "advisory" is that the current set of functions for
> accessing them doesn't enforce anything. That doesn't make the locks
> themselves any more or less user-defined than they were before ---
> certainly the pg_locks view has got nothing to do with whether they are
> advisory or enforced. I do not see a good reason to change it.
>
> It might be worth mentioning in the description of the pg_xxx_lock
> functions that the locks they acquire are shown as "userlock" in
> pg_locks, but that seems sufficient.
My point is that if you are going to call them user locks, you then are
going to have to call them userlocks in the documentation, which seems
pointless, considering that 99% of people who use pg_locks are not
applicadtions but users monitoring the system. I just don't see a
problem with making it consistent. I don't see the column rename as an
API change issue.
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +