Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
>> > Well, actually, a cursory check amongst database backends in the
>> current (and older) Pike versions shows:
>> - 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
Hmmm, indeed.
>only one backend, it's in my world the by far most important one.
I understand that, that's why I listed it as the first one.
Incidentally, (my own) benchmarks show that for the single-threaded
simple queries (few tables) with less than 10 rows of dataresults, MySQL
outperforms PostgreSQL by a factor of two. However, performance of MySQL
steadily drops for larger resultsets, more tables and multithreading;
whereas PostgreSQL's performance stays roughly the same.
>> - pgsql string/float/int
>This is your new one, right? Then, I'm sorry to say, it has little
>relevance in this discussion.
I only included it for comparison, not to bring weight to the argument;
I already figured that the MySQL driver would be the most compelling
example.
What set me off on the wrong foot, probably, were comments in the
Postgres driver which *complained* about the fact that the postgres
libpq libs "only" return strings and not binary formats.
It seems that through the years, the Sql interface wanted to have real
types, but slowly mutated to strings only.
>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.
I think I missed that discussion, but maybe it was held before I started
reading pike-devel.
>> + // 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.
>Thought I recognized that comment. ;) Actually, in a pike module that
Never create what you can steal ;-).
>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".
Well, a NULL value basically has any type (in SQL). I'm not sure what
would be the most natural way to extend this into Pike, but I figured
that the closest we could get, was something like the code above.
Since the NULL value has "any" type, it's not lying as such.
>> + 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.
The problem is, the NULL value *can* be casted to any type, it's just
that the result for any types other than the ones mentioned above is
just that: undefined.
--
Sincerely,
Stephen R. van den Berg.
Auto repair rates: basic labor $40/hour; if you wait, $60; if you watch, $80;
if you ask questions, $100; if you help, $120; if you laugh, $140.
