--- [EMAIL PROTECTED] wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> >
> > As a possible extension one could see sqlite3_create_function taking an
> > optional argument with a hint as to its return type that sqlite may use
> > for sqlite3_column_decltype. But SQLite does not currently return any
> > column types for any ad-hoc expression. So this would not be a trivial
> > change.
> >
>
> The code changes are not that complex. The hard part is getting
> me to agree to such a change. Surely by now you have come to
> better understand my views toward static typing....
No doubt.
This issue comes up frequently when making database drivers for
JDBC, ODBC, R, (you name the language) as they often expect static
column types in result sets. Yes, I've hacked my way around it,
as has every other driver writer, but it would be nice if everyone
did not have to reinvent the wheel each time.
In a hypothetical implementation, one could preserve backwards
API compatiblity by overloading the zFunctionName argument by
tacking on a TYPE suffix (i.e., "myfunction:TYPE") to convey the
type being returned by the function.
int sqlite3_create_function(
sqlite3 *,
const char *zFunctionName,
int nArg,
int eTextRep,
void *pUserData,
void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
void (*xStep)(sqlite3_context*,int,sqlite3_value**),
void (*xFinal)(sqlite3_context*)
);
But it would probably be easier to convince all the other popular
relational databases that they should change to exclusively use
dynamic typing.
;-)
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
