Re: function overloading question

I am doing this to accomadate the ProCobol developers we have here. They don't like to add a number of data conversions into what they are doing and they need to have it in a yyyymmdd format for things that have already been written to work right. I realize that doing the conversion inline would be better but I figured that giving them what they want would be easier done like I did it. I was just wondering if using the function in the package like a subroutine in say Perl was a common pratice in the Oracle world.

Adam

rivenu_at_hotmail.com (srivenu) wrote in message news:<1a68177.0202252240.49e8a3d4_at_posting.google.com>...
> Well i wouldnt bury the varchar to date conversion in the function.
> Well in the conversion of varchar to date you are not taking hours,
> minutes into consideration.
> So if tomorrow if you want them also you have to change the function.
> Also why do you need to overload the function?
> You can just do the conversion in the program which is going to call
> this function.
> Please tell me if i got it all wrong.
> thanks
> srivenu
> hap_at_mikomi.org (Adam Hapworth) wrote in message news:<a6cb04db.0202250807.3ea0a389_at_posting.google.com>...
> > I have a function that takes in a date and returns a date but now my
> > users wants it to take in a varchar2 and return a varchar2. I was
> > wondering if it is a good pratice to do it this way or not. All I did
> > was do a data_type conversion and then passed it to the original
> > function and returned the value. Like so
> >
> > function A (d in date) return date
> > is
> > begin
> > --date manipulation
> > return d
> > end A;
> >
> > function A (v in varchar2) return varchar2
> > is
> > foo date := to_date(v,'yyyymmdd');
> > begin
> > return to_char(A(foo), 'yyyymmdd');
> > end A;
> >
> > or should I just recreate the entire function instead of making the
> > call to the overloaded function basically twice. this only happens if
> > they want a varchar2 input and output from the function.
> >
> >
> > Adam
Received on Tue Feb 26 2002 - 13:03:57 CET