Re: Getting a ResultSet for a refcursor element.

Nic Ferrier wrote:
> Barry Lind <blind(at)xythos(dot)com> writes:
>
>
>>But now we essentially have two types of ResultSets, regular ones and
>>refcursor ones. Refcursor ones need to be treated differently, because
>>if you want to do the above the refcursor based result set can't
>>populate its results until you attempt to get the results (i.e. call
>>next()), this is because if you do intend to pass it on you can't get
>>the results because then the called function will have nothing to fetch
>>since the data will already be fetched.
>>
>>Also it wouldn't be appropriate to pass any old result set in as a bind
>>since only refcursor result sets could be passed on.
>>
>>But perhaps there is a middle ground between our two view points of view
>>that combines them.
>>
>>You are suggesting getting a refcursor returns a regular result set, I
>>am suggesting it returns a special object that retains the pointer
>>characteristics of a refcuror.
>>
>>By combining these ideas we could do the following. Introduce a new
>>object RefCursorResultSet that extends ResultSet. It basically acts as
>>my wrapper object and can be passed on to other function calls. However
>>at the same time it can also fully implement ResultSet. So that once
>>you call next() it will actually go out and fetch the data from the
>>refcursor. So I would see the implementation of this object as having a
>>method like String getCursorID() that would return the refcursor name.
>>It would also have a member variable that would be the real result set.
>> The implementation of next() would initialize the member the first
>>time it was called and then it and all other methods from ResultSet
>>would simply call the corresponding methods on the internal ResultSet
>>object.
>>
>>How does this sound?
>
>
> That sounds great. That is very like what Oracle does.
>
> Note that I am not opposed to your idea, I think it's a good
> idea. However, I have a need to keep Oracle compatibility in this
> area (because I'm porting lots of code).
>
> But if you're happy with the above, then I'll resubmit the patch on
> that basis.
>
>

Go ahead. I look forward to your patch.

--Barry