I've found a lot of package creation scripts that create an inline function just to call another existing function, when they could just call that function right out of the script:

create function inline_0 ()
returns integer as'                                                                                    
begin                                                                                                  
    perform acs_object_type__create_type(                                                              
        ''forums_forum'',                                                                              
        ''Forums Forum'',                                                                              
        ''Forums Forums'',                                                                             
        ''acs_object'',                                                                                
        ''forums_forums'',                                                                             
        ''forum_id'',                                                                                  
        ''forums_forum'',                                                                              
        ''f'',                                                                                         
        null,                                                                                          
        ''forums_forum__name''                                                                         
    );                                                                                                 
                                                                                                       
    return null;                                                                                       
end;' language 'plpgsql';

select inline_0();
drop function inline_0();

As you don't do anything with the return value here, I wonder what's the reason for the use of that inline function. As a counter-example here's how Jeff does it in his Photo Album:

 select content_type__create_type (
   'pa_album',               -- content_type                                                           
   'content_revision',       -- supertype                                                              
   'Photo album',            -- pretty_name                                                            
   'Photo albums',           -- pretty_plural                                                          
   'pa_albums',              -- table_name                                                             
   'pa_album_id',            -- id_column                                                              
   null                      -- name_method                                                            
 );

I'm not saying these old scripts should be changed, since it doesn't harm anyone if they use inline functions. I'd just want to point out that you don't have to use inline functions in order to call another function unless you a) need to use the return value of that function later, or b) need to call that function in a loop for many entries.

If I haven't understood something totally wrong, that is

Dan Wickstrom automated some of the porting of the datamodel from Oracle and PG.  I'm not 100% sure but this might be an artifact of automated porting ...

There's absolutely no need to do this, as has been pointed out, and our docs shouldn't suggest it.  You only need to do it if you need the result of one function call to pass as a parameter to another function.

Yes this is an artifact of automated porting, and it shouldn't be taken as a recommended practice for porting to postgresql.  Inline functions correspond to oracle inline code statements, and they end up being redundant in postgresql when a single function is being called.

A development FAQ would be nice, a development "best practices" document would be better...

Hi Joel,

Would you like to take over the Do and Don't FAQ?  I will give them to you if you want.

Hi Joel,

Not sure.  But the Do's and Don't was geared towards developers with some experience with OACS.  Even some of the oldies would get some info out of it.  I made this up so we can finally have a definitive guide.  I think it was supposed to make it in 4.6.x but I think it was such an odd ball that it never made it.  So I guess maybe you can get it and see where it is best to put it into the docs.  So it finally goes in.

One of the reasons I stopped maintaining it actively because feedback slowed down.  It is likely since its only liked in this forums.  Much of the knowledge on this forums are buried after a while.  Since its coming up again, why not finally put it into the docs or something.

I think it is even more important to clean up the code because it is the prime reference to every programmer!

For example when I played around with the postgres version of the logger I just looked at other code and found the somewhat peculiar-looking stuff with inline functions. Not having a real clue of Postgres I just took up on that trick...

I agree that the code itself is the first point of reference.  So all we need is for all of the kernel code to precisely match the current conventions.  hahaha.  Okay, while we are waiting for the technology to clone Don (and hypnotise the clones into working on OpenACS), should we pick a single package to be the "perfect" package?  It should be one of the core packages; it should show a variety of different techniques; it shouldn't have any clever tricks; it should be fully code-reviewed by several people on a recurring basis; and the maintainer should commit to keeping it current with changing coding standards.