> >Therefore I don't really see the point with the change in 7.8. Note
> >also that a mapping cannot carry UNDEFINED as a value for natural
> >reasons, so in Sql.query() those UNDEFINED's still becomes normal
> >zeroes.
>
> Aaargh. Didn't know that.
That's the raison d'être for UNDEFINED, to be able to see if a mapping
lookup failed to find the key. Unfortunately that semantic has gotten
severely muddled since many are very anxious to use it as a sort of
NULL value (the name "UNDEFINED" is actually rather well chosen).
> > Well, actually, a cursory check amongst database backends in the
> current (and older) Pike versions shows:
>
> Returns
>
> - Mysql string/float/int
Your check appears to be a little too cursory; this case is string
only (since OLD_SQL_COMPAT is typically not defined). Although it's
only one backend, it's in my world the by far most important one.
> - Oracle string/float/int
Probably true. The Oracle driver has always been a bit odd. It's
unfortunate that this semantic isn't uniform across all drivers. But
still, string only is the standard. Much of the code I'm concerned
with (e.g. Roxen) would break quite a bit if it's anything else. The
Oracle module ought to be fixed, but it requires compat of course.
> - pgsql string/float/int
This is your new one, right? Then, I'm sorry to say, it has little
relevance in this discussion.
> Well, in light of learning that mappings cannot contain UNDEFINEDs, I
> propose to introduce the following SqlNULL() type which should be returned
> by any mappingvalues from Sql.Sql()->query() which are actually an SQL
> NULL type.
An Sql.NULL value would be good, but this would also need new API
calls, since I stubbornly maintain that query and big_query should
return values as either string or 0. This has been up for discussion
earlier, actually, and iirc the proposed names for those new functions
were typed_query and big_typed_query, respectively.
> +class SqlNULL
> +{
> + constant is_SqlNULL = 1;
> +
> + // Treat these objects as indistinguishable from each other. We
> + // ought to ensure that there's only one in the pike process
> + // instead, but that's tricky to solve in the PCode codec.
> + protected int `== (mixed other) {
> + return zero_type(other)
> + || objectp(other) && other->is_SqlNULL;
> + }
Thought I recognized that comment. ;) Actually, in a pike module that
uniqueness problem shouldn't exist, so the kludge isn't necessary.
> + protected int(0..1) _is_type(mixed type) {
> + return 1;
> + }
I'm not sure this is a good idea. Is there a good palpable reason to
"lie" in type checks like this? Because if there isn't, then the
default, I think, is "don't".
> + protected mixed cast(string to) {
> + mixed ret=UNDEFINED;
> + switch(to) {
> + case "string":
> + ret="";
> + break;
> + case "float":
> + ret=Math.nan;
> + break;
> + case "mixed":case "object":
> + ret=this;
> + }
> + return ret;
> + }
Casting to unsupported types ought to throw errors, not silently
return UNDEFINED.
> + protected int __hash() {
> + return 17;
> + }
This is the second part of the kludge above. It can be removed too.
