"
They're easy to recode, and the resulting query works in both Oracle and PG so you don't need to split into separate queries for this reason alone. I've been trying to get aD to use these rather than the Oracle-isms but obviously with no success thus far. They do exactly the same thing."
While I agree that they are easy to port, I think it makes following the aD releases easier (less line noise in the diffs) if we don't change them from their nvl and case form. This thinking also applies to other oracle functions that we will come across. I think one of our goals in porting should be to minimize the changes we make to the .tcl files whenever possible as long, as we don't impact performance significantly.
"An additional reason for rewriting the query to use proper SQL92 forms is that IB tends to support proper SQL92. If we rewrite the queries to use "coalesce" and "case" we're part-way home for a port to other DBs that follow the standard."
It would be nice to have everyting sql92 compliant, but right now an interbase port seems kind of remote, while the likelyhood that we will need to maintain openacs4 relative to future releases of acs classic seems high. I tend to think that we should concentrate on miminizing our support hassles.
On the other hand, I think if Bryan can influence aD to use sql92 features as much then this whole discussion is moot, and we should go ahead use the sql92 constructs.
Bryan,
Do you think that future releases of acs 4.x will actually switch to using sql92 constructs whenever possible?
