question about locking (and documentation thereof)

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/ ...