> >> Vlad and Dmitry,
> >> Thanks for your answers, but then what about this part of the
> >> original question:
> >>> When I make a call to isc_dsql_describe_bind(), the XSQLVAR sqltype
> >>> values that are returned do not have the null indicator flag set. Is
> >>> this by design? To me, it looks like an oversight.
> > As i understand this is not an regression in FB2 code so i'm
> > not sure
> > it must be fixed now (at RC stage). If there are strong needs it
> > can be
> > fixed (by myself or Dmitry) of course.
> Well Vlad, I can't tell if that must be considered a strong needs or
> not, especially compared to anything else. Just that indeed, for
> EXECUTE PROCEDURE, it is not a regression in FB2, it was as wrong in
> FB 1.5. But for EXECUTE BLOCK at least it is a nice new feature
> introduced with a (yes, minor) defect. If that is sufficient to
> decide to fix it for EXECUTE BLOCK, then it might as well be fixed
> for EXECUTE PROCEDURE at the same time.
> In layers of code between applications and the database API, it is
> quite easy to correct on the fly, assuming that because the statement
> type is an EXECUTE PROCEDURE, the parameters descriptions can be made
> nullable even though the API didn't say so. Though for the EXECUTE
> BLOCK, the game becomes more tricky because it sometimes declares
> itself as a SELECT statement and not always as an EXECUTE PROCEDURE.
Why the game becomes more tricky for EXECUTE BLOCK ?
describe_bind() always described input parameters despite of kind of statement
> There are no nice way to workaround this in layering code, other than
> parse the sql statement (which is not the job of such a layer).
Sorry, i don't understand. Can you show me example, please ?
> I think there is much less risk to break applications by fixing this,
> late in the beta, than to release the software as is. Some
> application code will never be concerned, but any application
> following, in confidence, what the engine describe about the
> parameters (can be made null or not), will erroneously refuse to
> assign a NULL to parameters. This is already true in FB 1.5 for
> EXECUTE PROCEDURE. I'm not sure this (even very minor) defect should
> be promoted to the EXECUTE BLOCK.
One more question - i'm slightly confused about subject of discussion:
are we talking about nullable flag (least significant bit of XSQLVAR::sqltype)
or about NULL-indicator (XSQLVAR::sqlind) which is proposed to set to -1
by dsql_describe_bind() ?
PS proposed fix to make all input parameters nullable for EXECUTE BLOCK
cvs -z9 diff -u -wb dsql\pass1.cpp (in directory E:\FB2\fb2.head\src\)
RCS file: /cvsroot/firebird/firebird2/src/dsql/pass1.cpp,v
retrieving revision 1.259
diff -u -w -b -r1.259 pass1.cpp
--- dsql/pass1.cpp 14 Mar 2006 10:57:11 -0000 1.259
+++ dsql/pass1.cpp 28 Mar 2006 21:58:17 -0000
@@ -748,6 +748,8 @@
+ field->fld_flags |= FLD_nullable;
set_parameter_type(request, temp, desc_node.get(), false);
} // end scope
***** CVS exited normally with code 1 *****