in the docs regarding locking paradigms, this part makes sense to me:
Take a SHARE ROW EXCLUSIVE lock on a primary key table when going to
perform a delete operation:
BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM films_user_comments WHERE id IN
(SELECT id FROM films WHERE rating < 5);
DELETE FROM films WHERE rating < 5;
COMMIT WORK;
no problem -- lock the table, delete from subsidiary table, then purge
previously referred-to records in the master (locked) table.
but just above that example, there's this:
BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films
WHERE name = 'Star Wars: Episode I - The Phantom Menace';
-- Do ROLLBACK if record was not returned
INSERT INTO films_user_comments VALUES
(_id_, 'GREAT! I was waiting for it for so long!');
COMMIT WORK;
"select id"? where does it go to? can any selected field be later
referred to as _fieldname_ somehow? i've not yet found that in
the docs anywhere...
i was looking for how to take advantage of 'select for update'
and this ran across my radar. what's up?
--
DEBIAN NEWBIE TIP #104 from Sean Quinlan <smq@gmx.co.uk>
:
Looking to CUSTOMIZE THE COLORS USED BY LS? I find its easier
to run "dircolors -p >~/.dircolors" and then add "eval
`dircolors -b ~/.dircolors`" to my .bashrc and then make all
changes to ~/.dircolors (instead of the system-wide
/etc/DIR_COLORS). Probably more pertinent on a multi user
system, but good policy nevertheless.
Also see http://newbieDoc.sourceForge.net/ ...
