Subject Re: [Firebird-Architect] Fetching from a non-cursor
Author Alex Peshkoff
On 10/13/10 21:52, Dmitry Yemanov wrote:
> All,
> There was a private discussion going on for some time without getting
> anywhere close to the agreement, so I'd like to make it public in a hope
> to get more opinions.
> In all IB/FB versions, it's possible to execute apriori singleton
> statements (EXECUTE PROCEDURE, INSERT RETURNING) with either
> isc_dsql_execute() or isc_dsql_execute2(out_sqlda=NULL), i.e. without
> returning the output values in the same round-trip.
> I'm trying to understand how this behavior should be formally treated:
> 1) as correct and results should be discarded after execution
> 2) as wrong and error should be thrown (no room to store output values)
> 3) as an incomplete operation waiting for isc_dsql_fetch() to get the
> results

Is it only me with strong feeling of deja vu?
Look at this configuration parameters: OldParameterOrdering and
OldColumnNaming. I'm sure that if we break compatibility with old
documented behavior, quite soon we will have to have OldNonCursorFetch
in firebird.conf.

I can agree with breaking legacy behavior only when such break is
required to fix some other, more dangerous bug (like security one). But
I did not understand, what was the reason to break legacy behavior in
2.5. If it was only in order to fix foolish incompletely-documented old
API, I suggest to rollback this change. I can imagine how many legacy
software will suffer from it.