I'm going slightly crazy trying to work out how this works. The acs_subsite package has a proc called package_plsql_args in package-procs.tcl which very conveniently returns the arguments of a plsql/plpgsql function.

The proc has the following sql select:

    return [db_list select_object_type_param_list {
    select args.argument_name
                    from user_arguments args
                    where args.position > 0
                  and args.object_name = upper(:function_name)
                  and args.package_name = upper(:package_name)
    }]

I can't find the table 'user_arguments' to which this refers yet it works! Its used by e.g bt_bug in the bug tracker and that is working - I know cos I broke it and thats what lead me here.

Could someone please put me out of my misery and point out my stupid mistake :)

Ta
    Steve

Thanks.

Your quite right there is a query in package-procs-postgresql.xql which selects from acs_function_args. I didn't look in the xql because the db_list provided its own select statement. So I have learnt 2 things:

1. You can have a query in the xql and in the proc and the one in the xql overides the one in the proc (I would have expected this to be the other way around so that the query name can be overloaded easily in the proc).

2. The select statement in the proc is superfluous and could be removed. In fact if it points to a no existant table it perhaps should be removed to avoid confusion.

Does this sound right?

    Steve

Can we make it a rule, that no new code makes it into the CVS as long as it has SQL queries in the curlies? This is definitly confusing for newcomers. Though I have to agree that developing code is considerably easier with the queries in the TCL file, but hey, we got query-extractor :).

Can we post a rule book somewhere? Or, if it exists, make it more prominent at e.g. the doc section?

Just a n-pager stating: If you want to develop for the OpenACS core, these are the rules and good principles you should be following. Obviously, the rule about taking out SQL queries from tcl files should be high on that list .

c'mon mark... so you want (n' = n + 1) pages, and soon enough the documentation is infinitely long and then *noone* will read it...

I think this is a really good idea. If I'm given admin access on an ETP instance, I'll even volunteer to maintain this page. (I could do it on rubick.com, but openacs.org makes more sense).

A good start would be Jun's list of best practices:

http://www.infiniteinfo.com/openacs/things2remember.html

I'd probably start with that.

Hi Jade,

I have given the doc to Joel.  And hopefully it can be maintained in a central place.  I am not sure if it did make into the docs though.

I am happy to put in your additions.  Maybe we can just put it into file storage.