Forum OpenACS Development: Parameter limits and the CR

Collapse
1: Parameter limits and the CR
Posted by Reuven Lerner on 05/21/03 04:33 PM

I'm working on a simple CMS for a client that'll be based on OpenACS 4.6.3 and PostgreSQL 7.2.4. I decided that there's so much overlap between the client's request and the news module that I'll just modify the news module.

So far, so good. But now I see that every article in the news module is split between a table (really an OpenACS object) and items in the content repository.

OK, that's not a problem -- until I discover that the function news__new takes 16 parameters already. And PL/PgSQL functions have a maximum of 16 parameters in PostgreSQL 7.2.4.

I believe that I have several options, and wanted to know what was the best one:

  • Upgrade to PostgreSQL 7.3.x. I know that people have had problems with it, and I'm not interested in being a guinea pig right now.
  • Add the fields to the cr_news table, and call them attributes of the story, or
  • Add the fields to the news story in the content repository.

Any suggestions?

Reuven

Collapse
2: Re: Parameter limits and the CR (response to 1)
Posted by Don Baccus on 05/21/03 05:44 PM
If you have control of the system and if you have no plans to distribute the code so that compatibility with the standard PG 7.2.4 RPM isn't and issue, why not recompile PG 7.2.4 to allow 32 parameters rather than 16?  It's just a number in one of the global .h files.

PG 7.3.2 seems to work well, too, and in OpenACS 4.6.3 I think we've weeded out the last of the compatibility problems.  You can be sure we'll fix them quickly if you were to uncover any additional ones.  I've been running PG 7.3.2 for development of OpenACS 4.6.2 and 4.6.3 and haven't seen any PG problems (7.3.0 did have a couple of bad bugs.)

Anyway ... if at all possible I'd recommend you make life easy by either running PG 7.3.2 or by recompiling PG 7.2.4.

Also you can poach one parameter from news__news by getting rid of the creation_time parameter and using now() in the function body (assuming someone hasn't already done that in our standard sources.)  I wish we'd just done that in the first place when porting, there's no reason to allow for a creation time other than the time when it's created! :)

Use "timestamptz" rather than "timestamp" in any tables you define.  PG <= 7.2 defaults "timestamp" to "timestamptz" while PG >= 7.3 defaults "timestamp" to not carry tz info.  pg_dump does the right thing, but explicitly declaring "timestamptz" means the same datamodel source works equivalently in PG 7.2 and 7.3.