Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster