Forum OpenACS Development: multiple plpgsql

Collapse
1: multiple plpgsql
Posted by Jun Yamog on 03/19/02 10:38 PM
<p>Hi,

<p>In postgres we define 2 or more plpgsql functions that have
different args.  I did notice that some plpgsql functions that was
defined reorder their args rather than just add to it.

<p>Example.
<P>
function foo(name, email, id)
<br>function foo(email, name, group, id)
<br>function foo(id, name, group, email, address)
<p>Why are the args mixed from one function to another rather than using?
<p>
function foo(name, email, id)
<br>function foo(name, email, id, group)
<br>function foo(name, email, id, group, address)

<p>Is the reordering of the args in plpgsql intentional?  Or is it
just a case of bad coding?

Collapse
2: Response to multiple plpgsql (response to 1)
Posted by Roberto Mello on 03/20/02 02:31 AM
I'm not sure I understand what you're asking here... Are you referring to the OpenACS 4 code?
Collapse
3: Response to multiple plpgsql (response to 1)
Posted by Jun Yamog on 03/20/02 06:47 AM
Hi Roberto,

Yes I am refering to some Postgres function in OpenACS 4.  Take a look at content_item__new.

BTW nice work on the docs.

Collapse
4: Response to multiple plpgsql (response to 1)
Posted by Jowell Sabino on 03/20/02 02:52 PM
Postgres can only use a max of 16 parameters for its arguments, and unlike Oracle, you cannot use optional, non-position sensitive arguments. In the case of the content repository, Dan W. had to be "creative" in porting the CR API because most functions pass a lot fo arguments. In particular, at least 5 of the *__new functions come from arguments that are eventually passed on to acs_object__new.

The 16 parameter limit can be changed by a recompile of postgres, (see this thread) requiring people to change a default parameter in the source code and recompile postgres may be too much of a burden for a nascent project like openacs.

Collapse
5: Response to multiple plpgsql (response to 1)
Posted by Jowell Sabino on 03/20/02 03:26 PM
By "creative" I meant that when you are working on a max set of 16 parameters in postgres, you have to overload the function to take care of a wider set (more than 16) of possible arguments. But the only way for postgres to distinguish between overloaded functions is to make sure that their argument data types are different -- hence the need sometimes to reorder the arguments.

I didn't mean to imply that "creative" porting = bad coding.