Roberto> I can see use creating an nvl clone, but I don't see how
Roberto> to easily do that to decode, since it can take an
Roberto> arbritary number of arguments. We'd have to create a
Roberto> different decode function clone for each new argument.
It will be a little painful to create all of the overloaded versions of decode, but it's doable and probably less work than touching all of the .tcl files that will need to be touched for porting the decode statements to case when statements. It's also something that could be built up over time. Every time someone encounters a new decode form, instead of porting it to case when, they could just add the new form to postgresql.sql. The net result will be that as new packages are ported, the queries won't need to be touched to compensate for nvl, decode and other oracle functions.
Roberto> One thing that I want to ask is: are we going the easy,
Roberto> more maintainable route of creating functions to mimick
Roberto> Oracle's (e.g. nvl) or are we porting everything to PG's
Roberto> dialect? Supposedly the latter would have better
Roberto> performance (?) but it'll be harder to synch with aD's
Roberto> tree.
Based on the fact that we are bothering with a query dispatcher, I think the goal is to touch as little of the .tcl code as possible. This will make maintenance of the code easier and will minimize our porting effort. Creating our own nvl and decode statements and other oracle functions should not impact our performance greatly.
Right now when I grep in acs 4.x, I only find ~36 decode statements in the code and the majority of those are the simple four arguement case.
