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.