--- Scott Hess <[EMAIL PROTECTED]> wrote:
> On 6/14/07, Joe Wilson <[EMAIL PROTECTED]> wrote:
> > You can't infer a function's return type from its arguments.
> > Take the hypothetical function FOO(x). If I pass it a number, it will
> > return the number spelled out as TEXT, but if I pass it a BLOB it will
> > return its length*PI as a FLOAT.
>
> Would it be reasonable to have:
>
> SELECT myfunc(x, y, z);
>
> have an undefined return type, while:
>
> SELECT CAST(myfunc(x, y, z) AS INTEGER);
>
> would return a well-defined return type?
>
> After all, in SQLite you can't infer a column's type, either, you can
> only infer how the column is declared. What it actually contains
> could be anything at all.
True enough, but in spite of my contrived FOO function, I'd think
that 99% of functions would return one specific type or a NULL.
In the situations where this would not be the case, the CAST
operator, as you point out, would be a good way to override the
returned declared type.
I don't see this proposed type mechanism as being at odds with
SQLite's typeless nature - it does not detract from it. It's not
mandating policy - it's just suggesting a standard type reporting
convention which you may elect to use or ignore.
It also would provide a facility to return column types for
ad-hoc SELECT expressions that return no rows (i.e., you can't
infer the column types from the first row because there are no
rows returned from the query).
____________________________________________________________________________________
Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
