Re: WL#946 and Changing time literal format
* Konstantin Osipov [09/02/05 03:35]:
> > People are using MySQL because it's different and can satisfy their
> > needs. Standards are useful, but not important for our current or
> > future users. Getting the job done and not having downtime, even when
> > upgrading, that is important!
Hear, Monty, there has never been consensus about it even
among you and David :-).
- Forwarded message from David Axmark -
Date: Fri, 09 Jan 2009 11:01:26 +1000
From: David Axmark
To: Jay Pipes
Cc: drizzle-discuss Discuss
Subject: Re: [Drizzle-discuss] Vote/Discuss: FROM_UNIXTIME() behaviour
ERROR!
I have always hated the way MySQL has taken strings like 1232STRING as a
number. Leads to tons of stupid errors hidden deep in applications.
/David
On Thu, 2009-01-08 at 16:29 -0500, Jay Pipes wrote:
> All:
>
> mysql> SELECT FROM_UNIXTIME("2008-01-08 03:14:07");
> +--+
> | FROM_UNIXTIME("2008-01-08 03:14:07") |
> +--+
> | 1969-12-31 19:33:28 |
> +--+
> 1 row in set, 1 warning (0.00 sec)
>
> mysql> show warnings;
> +-+--+--+
> | Level | Code | Message
> |
> +-+--+--+
> | Warning | 1292 | Truncated incorrect INTEGER value: '2008-01-08
> 03:14:07' |
> +-+--+--+
> 1 row in set (0.00 sec)
>
> I was actually surprised to find this was the behaviour in MySQL and
> Drizzle.
>
> Would anyone have a problem if I converted the above to an error?
> FROM_UNIXTIME() only takes unsigned integers in the range of 0 to
> INT32_MAX. It doesn't take strings, or strings that "look like
> numbers", or anything of the sort.
>
> IMHO, the above behaviour is dangerous, as it:
>
> * Implicitly tries to convert a string to an integer (based on the warning)
> * Produces an invalid TIMESTAMP value
> * Doesn't error, therefore giving the unassuming user the impression
> that FROM_UNIXTIME() indeed takes string parameters.
>
> Anyone object to me making the above an error?
>
> Cheers,
>
> Jay
>
> ___
> Mailing list: https://launchpad.net/~drizzle-discuss
> Post to : drizzle-disc...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~drizzle-discuss
> More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : drizzle-disc...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
- End forwarded message -
--
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: WL#946 and Changing time literal format
* Michael Widenius [09/02/03 19:24]: > Konstantin> Monty, I disagree with this statement. Our current users use the > Konstantin> current versions of the server. It's a separate question of what > Konstantin> support we're willing to give them and for how long. > Konstantin> In the new versions we should hold high the expectations of new > Konstantin> users, and they are about standard compliance, and also about ease > Konstantin> of migration. > Sorry, but the above is not true. We have asked user over and over > again what they think about the standard and they have said it's not > critical or even important to them.; What is important that we don't > break their old applications! Obviously, we talked with different people. > When going forward, we must prioritize old user to new ones! > The old ones are our current or customers in the near future. If we > make them unhappy we don't have a business anymore. There is a way to introduce incompatible changes and retain your existing users. Trying to stay compatible is, sorry for a popular cliché :-p, like trying to hide one's head in the sand: we can't, anyway, we broke backward compatibility with 4.1, 5.0, and will break it with 6.0 and 6.1. Change management is what we need to be doing instead. > The new users will mainly listen to old user if they should use MySQL > or not. If we make the old ones angry, we don't get new users. I yet have to find an old user who would be particularly happy about our sloppiness with input. Users put aside, I am yet to meet an(other) engineer who would support it. And engineers matter no less than users: without being able to attract new engineers to the project, we're dead in the water. Just look around: no other database has this "feature": postgres, the big 3, even our own drizzle killed it in the first 3 months after the fork. Any feature can be implemented. Nevertheless, clear and simple requirements is key to product simplicity and efficiency. MySQL doesn't even yet support SQL92 foundation, but is already a very convoluted piece of software. > Konstantin> MySQL server needs a vision. Sticking to expectations of existing > Konstantin> users is looking back into (not-so) glorious past. > > Our existing users is the second biggest user base for any database. > We reached this level as MySQL has worked to their expectations. > Trying to do things differently, like other companies have tried, will > just lead to failures. Old expectations are met, let's get over it. If we don't try to do things differently (but better), we could just as well stop new development completely. > People are using MySQL because it's different and can satisfy their > needs. Standards are useful, but not important for our current or > future users. Getting the job done and not having downtime, even when > upgrading, that is important! It's possible to meet the standard and provide an upgrade path to people. It's hard, but it's a payback for telling users for 15 years that sloppy input is okay. > I agree that we need to change things. I disagree that doing > incompatible changes without planning and carefull thinking about how > this will affect our user base is the right way to go. +1 on that. -- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: WL#946 and Changing time literal format
* Michael Widenius [09/01/30 14:53]: > Its more important that we don't break things for current users than > try to be concerned about possible wrong usage that no one seams to do > or find important enough to complain about. Monty, I disagree with this statement. Our current users use the current versions of the server. It's a separate question of what support we're willing to give them and for how long. In the new versions we should hold high the expectations of new users, and they are about standard compliance, and also about ease of migration. sql_modes are not a solution since they make the server code a mess, and won't let us make everyone happy anyway. MySQL server needs a vision. Sticking to expectations of existing users is looking back into (not-so) glorious past. Trying to make everybody happy is infeasible. Our only option is to move forward to meet expectations of our modern adopters, and they are largely more intelligent, with past database experience, so the standard compliance is high on their list. What's worse, is that while we're fighting internally when to make an incompatible change and when not, our change management process is a mess. We introduce incompatible changes in every major release, so people are forced to migrate their applications manually again and again. And yet we can't plan our changes in a way that a bulk incompatible changes in a certain area are done at once, forcing people to look into the problem once only, rather than on every upgrade. It's a pity we can't shift our focus and mental efforts from developing a shared understanding what incompatible changes are right and called for, to developing the best way of making changes. -- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Streaming LOB Data
* Robert DiFalco <[EMAIL PROTECTED]> [06/04/30 03:09]: > Thanks Sergei, it's nice to know for sure. Do you know if there is any > documentation on how memory is used to store LOB data? For example, is > it a percentage of the total buffer pool size or is it allocated from > available memory un-allocated to the buffer pool size? There is no streaming interface between the SQL layer and the storage engines layer. An engine operates with at least one column, not with a piece of a column (one exception is that we can use row IDs when walking through records in a join, in this case the LOB is not loaded). So, at first the LOB is assembled on the SQL layer (e.g. if you supply a LOB object in pieces via mysql_stmt_send_long_data), and then submitted to the storage layer. This means than when inserting a LOB the server creates at least two copies of it in memory - on the SQL layer and on the storage layer. If instead of mysql_stmt_send_long_data you use the text protocol and simply encode the LOB in the query text with mysql_real_escape_string, you get one more copy - in the text of the query itself, which is also kept in memory. -- -- Konstantin Osipov Software Developer, Moscow, Russia -- MySQL AB, www.mysql.com The best DATABASE COMPANY in the GALAXY -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL C API documentation
* Michael Widenius <[EMAIL PROTECTED]> [02/03/26 12:41]:
> Konstantin> class Cursor
> Konstantin> {
> Konstantin>Cursor(MYSQL_RES *res):_res(res) {}
> Konstantin>bool fetch() { return mysql_fetch_row(_res); }
> Konstantin>Row row() { return Row(_res->current_row); }
> Konstantin>~Cursor() {
> Konstantin> while (!mysql_eof(_res) && mysql_fetch_row(_res))
> Konstantin> ;
> Konstantin> mysql_free_result(_res);
> Konstantin>}
> Konstantin> };
> Konstantin> In this code snippet I have to problems.
> Konstantin> First, that I can't simply return to user current row without
> Konstantin> moving the cursor to next row: there is no C API function like
> Konstantin> mysql_current_row().
> Konstantin> Nevertheless, MYSQL_RES always stores current row in member field
> Konstantin> 'current_row', so I have to use this undocumented feature
> Konstantin> (I can have my own current_row, but why should I?)
> I couple of comments about the above:
>
> - The code above would be safer against the future if you in the class
> cursor stored the value from mysql_fetch_row and returned this in your 'row'
> function, instead of relying on mysql->current_row.
I've realised eventually that You have reasons not to provide access for
mysql_res->current_row, and I do store my own copy of current_row in Cursor.
> In the ~function, you don't have to call mysql_fetch_row().
> mysql_free_result() will do this for you.
But, according to MYSQL C API documentation, 8.4.2,
(http://www.mysql.com/documentation/mysql/bychapter/manual_Clients.html#C_API_function_overview)
I have to do this:
"An advantage of mysql_use_result() is that (...)
(...)
Furthermore, you must retrieve all the rows even if you determine in
mid-retrieval that you've found the information you were looking for."
> Anyway, it would still be nice if you could send your questions to
> [EMAIL PROTECTED] instead of directly to me; I do get +300 emails
> per day and I simple don't have time to answer all questions direct to
> me :(
Sorry && thank you.
--
WBW, Konstantin Osipov
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
C API help: mysql_fetch_row(mysql_res)
Hi!
Is this code buggy?
...
mysql_res = mysql_store_result(mysql);
if (mysql_errno(mysql) == 0 && mysql_num_rows(mysql_res) > 2 &&
mysql_num_fields(mysql_res) > 2)
{
MYSQL_ROW row1 = mysql_fetch_row(mysql_res); // can i fetch several rows
and then work with them?
MYSQL_ROW row2 = mysql_fetch_row(mysql_res); //
if (row1[0] == row2[0])
printf("equal\n");
}
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
С API help
Hi All! Is this code buggy? -- MYSQL* mysql = new MYSQL; mysql_init(mysql); mysql_real_connect(mysql, "localhost"); /* some work*/ mysql_close(mysql); mysql_real_connect(mysql, "otherhost"); /* some work*/ mysql_close(mysql); delete mysql; -- In other words, if struct MYSQL allocated manually, should i call mysql_init(mysql) after mysql_close(mysql) if i want to connect using this struct to other database? WBW, Konstantin - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
