Обсуждение: idiom to move records?

Is there a handy way to move a set of records to a different
table in sql?  I'd like to do this based on a WHERE clause
and have it work atomically such that it will not lose new
records added between the step that copies to the other table
and deleting the copied records.

   Les Mikesell
     les@mcs.com

At 7:31 +0200 on 26/10/98, Leslie Mikesell wrote:


> Is there a handy way to move a set of records to a different
> table in sql?  I'd like to do this based on a WHERE clause
> and have it work atomically such that it will not lose new
> records added between the step that copies to the other table
> and deleting the copied records.

Do it in a transaction, then. Assuming that the target table is defined
(not a temporary table you create ad-hoc), you do:

BEGIN TRANSACTION;

LOCK TABLE source_table;

INSERT INTO target_table (col1, col2, col3)
SELECT (expr1, expr2, expr3)
FROM source_table
WHERE <where condition here>;

DELETE FROM source_table
WHERE <where condition here>;

COMMIT;



Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma

>
> Is there a handy way to move a set of records to a different
> table in sql?  I'd like to do this based on a WHERE clause
> and have it work atomically such that it will not lose new
> records added between the step that copies to the other table
> and deleting the copied records.

    Use a transaction and lock the source table first.

        BEGIN TRANSACTION;
        LOCK TABLE src_table;
        INSERT INTO dest_table SELECT * FROM src_table
               WHERE ...;
        DELETE FROM src_table WHERE ...;
        COMMIT TRANSACTION;

    No  other  backend  can add, modify or remove rows to/in/from
    src_table while you have a lock on it.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

On Mon, 26 Oct 1998, Jan Wieck wrote:

>     Use a transaction and lock the source table first.
>
>         BEGIN TRANSACTION;
>         LOCK TABLE src_table;

Jan & Herouth,

I've been using this for some time but lately lots of data is going
into the system (hope this means more revenue as well ;-)

My point:  when attempting to do a SELECT the table lock blocks even
this activity.  Is this a bleeding lock?  Shouldn't a simple SELECT
succeed?  I dunno...but this is problematic as users are looking for
info while the data entry person is doing her thing...ouch.

Another bit of whining: in my PROGRESS dbs the user gets a NOTICE
when a table is LOCKED and his/her SELECT is on hold:
`tablename is in use by doofus on term/1a11...press CTRL-C or Wait'
Is there a way to implement this with pg?

 Cheers,
 Tom

    ----------- Sisters of Charity Medical Center ----------
                    Department of Psychiatry
                              ----
 Thomas Good, System Administrator            <tomg@q8.nrnet.org>
 North Richmond CMHC/Residential Services     Phone: 718-354-5528
 75 Vanderbilt Ave, Quarters 8                Fax:   718-354-5056
 Staten Island, NY   10304                    www.panix.com/~ugd
                              ----
 Powered by PostgreSQL 6.3.2 / Perl 5.004 / DBI-0.91::DBD-PG-0.69

At 15:18 +0200 on 26/10/98, Thomas Good wrote:


> My point:  when attempting to do a SELECT the table lock blocks even
> this activity.  Is this a bleeding lock?  Shouldn't a simple SELECT
> succeed?  I dunno...but this is problematic as users are looking for
> info while the data entry person is doing her thing...ouch.

This lock is an exclusive lock. There is no other kind of lock in Postgres.

One may give up the LOCK at the beginning of the transaction. This would
mean that if a reader came and went before the deletion of the record, it
would succeed, because up to that point the transaction holds a shared lock
on the table. If a writer appeared, then it would fail, because it would
try to change the lock on the table from shared to exclusive, which it
can't do until all readers relinquished their locks.

This, however, creates a possibility that the deletion phase (and the
entire transaction) would fail, because the lock would fail to convert to
exclusive because other readers are still holding it.

Herouth