Roy Lyseng wrote:
Jay Pipes wrote:
Roy Lyseng wrote:
Jay Pipes wrote:
Roland Bouman wrote:
Gosh - i must've been at the KB for too long today - I forgot to paste
my table def....
sorry - all, here goes:
mysql> create table t(c char(10) );
Query OK, 0 rows affected (0.13 sec)
mysql> insert into t values ('0123456789');
Query OK, 1 row affected (0.08 sec)
mysql> select cast(c as char(9)) from t;
+--------------------+
| cast(c as char(9)) |
+--------------------+
| 012345678 |
+--------------------+
1 row in set, 1 warning (0.06 sec)
Warning (Code 1292): Truncated incorrect CHAR(9) value: '0123456789'
OK, so I still don't see the value of the warning in this case.
What value does it give? If you did the following:
SELECT CAST(c as CHAR(9)) FROM t;
SELECT LEFT(c, 9) FROM t;
The first would raise a warning, but the second would not. So, I
ask again, what real value is the warning in this case?
Currently, we have actually 3 levels:
ERROR, WARNING, and NOTE.
I could see the possible value of outputting a NOTE in this case:
SELECT CAST(c as CHAR(9)) FROM t;
But not a warning. By doing an explicit CAST(), you are essentially
saying to the server "Yes, I know what I am doing, don't warn me
about stuff...".
Roland is right, of course. You might argue that this should be a
Warning or a Note, but the operation is nevertheless executed.
Not quite sure what you mean here...could you elaborate? I have a
local branch where I've done the coding to eliminate warnings (turn
everything into a real error) and it's scary how much shit is simply a
warning and not an error (Division by zero anyone?!)
I'd love to get to the point where we are not throwing a warning for
*anything* which modifies data in a table and has bad input...
Short story - I totally agree with Roland on this matter. Having a
standard that dictates behaviour is very valuable in this situation,
even hough you may not be completely happy with the semantics at all times.
I share your concerns on whether this should be a "warning" or a "note",
but (as Roland points out) there are no "notes" in the standard. It's
either a warning, a successful completion or no data. Given these
choices, the obvious one (to me) is warning.
But I guess you are a bit biased after looking anxiously for MySQL
warnings through several years - it's not that much of a deal when
you're standards compliant :)
Yes, but being standards-compliant doesn't solve the issue even. Does
the standard detail *every* situation which should error and which
should throw a warning?
As far as the standard defines semantics, the answer is yes. However,
you may have implementation-defined behaviour in addition, and that
behaviour may also define warnings.
The really great thing with standard-defined warnings is that the
behaviour is still defined in detail.
Didn't notice this wasn't to the list...added drizzle-discuss.
OK, then I think that conforming to the SQL standard is very valuable in
this case. It just means one less thing to have to decide about...
Are people in agreement with this? Can we just stick to throwing
warnings where the standard says to do so, and errors likewise?
**IMPORTANT**:
This would likely mean the dropping of the IGNORE keyword from Drizzle's
SQL syntax.
Given the SQL standards, I think I can get Drizzle into
standards-conforming behaviour fairly quickly, at least in relation to
the INSER/UPDATE/DELETE/LOAD statements. Roy, I can work with you
offline on getting a copy of the standards in relation to what are the
standard warnings and what aren't.
Cheers,
Jay
-jay
Roy
-jay
Hope this is clear now...I ask the db to cast, it knows how to do it,
it does it, but it results in data loss -> warning.
This is in fact standard behaviour in case you're in doubt.
The NULL thing discussed earlier - well, that should have been an
error according to the standard. Reason: column is defined as NOT
NULL, so you *cannot* legally store NULL in it without breaking the
constraint. MySQL in that case does *not* do what we ask from it (we
asked to store a NULL, but instead it stores the 'datatype default'
wetf that may be) so that *should* have been an error - not a warning.
I hope this helps.
On Fri, Dec 19, 2008 at 10:12 PM, Sheeri K. Cabral
<[email protected]> wrote:
On 12/19/08, Jay Pipes <[email protected]> wrote:
FYI, if folks decide we can scrap warnings, I can mentor a community
member in the task of replacing warnings with errors. It's not a
particularly difficult task, basically broken into 4 phases:
1) Identify all code locations that emit warnings
2) Replace with errors
3) Remove the warnings system entirely
4) Fix EXPLAIN EXTENDED to not use SHOW WARNINGS afterwards (this
was
always a total hack)
-jay
While I agree with the ideas here, I don't think we can actually
scrap all
warnings without someone going through the warning codes and
making sure
there's no functionality being lost. There very well may be times
where we
want an error instead of a warning or having an error and a
warning for two
similar issues that are different in severity. No, I can't think of
anything concrete right now.
-Sheeri
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
