Forum OpenACS Development: In 5.3.0 final, unable to drop content type using content_type__drop_type() in pg-8.1.5

I'm going to try organizing the things I did and tried yesterday into a few focused pieces... first off, I tried starting to do the notes tutorial in the new 5.3.0 release, and the data model scripts which create and remove the content type weren't working properly together.

While the create script ran without problem (creating the type "mfp_note"), the drop script failed because the view mfp_notesi depended on existing objects and so couldn't be removed.

I was testing the two scripts and did not post any actual note data to the table, so it should have been empty at the time the drop script was run.

This led me to run the automated tests, which passed for the cr. This confused me; why would the tests pass if there was a problem? So I looked at the tests, and learned enough to add some tests which confirmed for folders, items and revisions that deleting them worked. When I add this same thing to all cr objects, I'll provide a diff; should be in a day or so.
Here is the diff that adds tests of various deletes (again, to 5.3.0 final, and again, wouldn't be a bad thing IMO to add them for 5.3.1)
This also led me to look at the code for content_type__drop_type() and I found some inconsistancies:

The api browser revealed there are two versions, one taking 3 parameters and the other taking those three plus one more.

One of the parameters in common to both calls tells whether the aux table associated with the type should be dropped.

The additional parameter in the four-argument version specifies whether the child types of the type in question should be dropped.

There is also a recursive call whose purpose is to drop child types; the four-argument version has this call enclosed in an if statement that checks the parameter.

One thing I found that was inconsistant, is that in the three-argument version, the parameter of whether to drop the aux table is not passed to the recursive call, but it is in the four-argument version.

Another thing I found, was that even though the original (oracle) code shows that the default for the parameter was to not drop the child types, the three-argument version does drop the children.

OK, this is wrong... just forget I wrote this part :)

Actually the extra parameter was whether to drop objects, not child types, and that part works fine. There is no code to drop the objects in the 3-argument version, and that satisfies the default case.

Finally, I'm interested in adding something like the following code to acs_object (to facilitate testing data model):

ad_proc object_exists {
    -id:required
} {
    @author Jim Lynch (jim@jam.sessionsnet.org)
    @creation-date 2007-01-26

    @param id

    @return true if object whose id is $id exists
} {
    set id \
        [db_string test_exists \
	     "select 
                  object_id 
              from 
                  acs_objects 
              where 
                  object_id = :id" \
	    -default "NULL"]

    set exists 0

    if {$id ne "NULL"} {set exists 1}

    return $exists
}

How about this

ad_proc object_exists {
    -id:required
} {
    @author Jim Lynch (mailto:jim@jam.sessionsnet.org)
    @creation-date 2007-01-26

    @param id

    @return true if object whose id is $id exists
} {
    return [db_string test_exists \
	     "select
                  1
              from
                  acs_objects
              where
                  object_id = :id" \
	    -default "0"]

}

OK, here is a patch that fixes cr's plpgsql funcs to delete content types
I just tried this patch on 5.4.1 and it works there as well.