Merlin Moncure wrote:
> > > This needs some revisions. The table needs to be mentioned somewhere in
> > > the
> > > text, so the reader knows when or why to refer to it. Also, the cryptic
> > > abbreviations need to be expanded or explained. And then the concept of
> > > lock "compatibility", as the table puts it, is not used anywhere else in
> > > the
> > > documentation. The table should be put in terms of conflicts instead.
> > >
> >
> > Another version with expanded abbreviations is
> > http://mira.sai.msu.su/~megera/pgsql/lockmatrix/c2.html, if remove
> > UPDATE EXCLUSIVE.
> >
> > While compatibility matrix is a commonly accepted termin, I agree, that
> > using conficts would be better in context of our docs.
>
> How about changing 'current lock mode' to 'opposing lock mode'?
> 'current' kind of suggests that you are escalating your own lock.
Not sure how you can say requested and opposing --- they seems odd
together. I am still open to new working though:
http://momjian.us/main/writings/pgsql/sgml/explicit-locking.html#TABLE-LOCK-COMPATIBILITY
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
