Skip site navigation (1) Skip section navigation (2)

Correct way to do deletes?

From: Bill Studenmund <wrstuden(at)netbsd(dot)org>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Correct way to do deletes?
Date: 2001-10-28 03:31:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I'm working on DROP OPERATOR CLASS, and have a question about how to
actually do the deletes. I ask as my main method has been to copy other
bits of the backend, assuming they do things right.

But I've found two different examples, and don't know which is right? Or
are they both?

Specifically I'm at the step of cleaning out the entries in pg_amop and

Example 1 from backend/commands/remove.c for aggregates:

    relation = heap_openr(AggregateRelationName, RowExclusiveLock);

    tup = SearchSysCache(AGGNAME,
                         0, 0);

    if (!HeapTupleIsValid(tup))
        agg_error("RemoveAggregate", aggName, basetypeID);

    /* Remove any comments related to this aggregate */
    DeleteComments(tup->t_data->t_oid, RelationGetRelid(relation));

    simple_heap_delete(relation, &tup->t_self);


    heap_close(relation, RowExclusiveLock);

Another apparently contrary example from backend/catalog/heap.c:

    pg_class_desc = heap_openr(RelationRelationName, RowExclusiveLock);

    tup = SearchSysCacheCopy(RELOID,
                             0, 0, 0);
    if (!HeapTupleIsValid(tup))
        elog(ERROR, "Relation \"%s\" does not exist",

     * delete the relation tuple from pg_class, and finish up.
    simple_heap_delete(pg_class_desc, &tup->t_self);

    heap_close(pg_class_desc, RowExclusiveLock);

In one we SearchSysCache(), simple_heap_delete(), and then
ReleaseSysCache(). In the other we SearchSysCacheCopy(),
simple_heap_delete, and heap_freetuple().

Are they two parallel ways, or is one better?

Take care,



pgsql-hackers by date

Next:From: mlwDate: 2001-10-28 03:38:53
Subject: Optimizer, index use, good news for 7.2b1
Previous:From: Joe ConwayDate: 2001-10-28 01:02:57
Subject: Re: storing binary data

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group