Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Time for a WTF MySQL Moment

gbl08ma.com

Post reply on HN
Print view View original

71–80 of 121 posts

Re: Time for a WTF MySQL Moment

#71

Post by cesarb »

WkndTriathlete wrote: post #67
cesarb wrote: post #55

Earlier quoted context omitted.

> even on 32bit linux systems, time_t is still 64bit No, on 32-bit Linux systems, time_t is 32 bits (except perhaps on newer ports like 32-bit RISC-V).

https://stackoverflow.com/a/60709400/571787 states otherwise with recent Linux kernels + glibcs.

Note that the glibc release mentioned there (2.32) has been released only two months ago (https://lwn.net/Articles/828210/), and its release notes don't mention time_t now being 64 bits. The glibc manual page linked to by that answer (https://www.gnu.org/software/libc/manual/html_node/64_002dbi...) says "at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available", which probably means in practice that 64-bit time_t is still not available for common 32-bit configurations (unless you want to lose binary compatibility with all existing software). I haven't been following this Y2038 work, but it's probably been postponed for a later glibc release (perhaps even the next one).

Re: Time for a WTF MySQL Moment

#72

Post by reaperducer »

speeder wrote: post #62
kochthesecond wrote: post #42

Earlier quoted context omitted.

Nice These three points has made me raving mad from working with mysql: - The default 'latin1' character set is in fact cp1252, not ISO-8859-1, meaning it contains the extra characters in the Windows codepage. 'latin2', however, is ISO-8859-2. - The 'utf8' character set is limited to unicode characters that encode to 1-3 bytes in UTF-8. 'utf8mb4' was added in MySQL 5.5.3 and supports up to 4-byte encoded characters.…

I am currently trying to fix a program that was made by a person that didn't knew those details of MySQL... Most weirdly, the fact that the default collation is SWEDISH. It is a complete freak show, the users kinda got used to it, butchering our language (portuguese) to use only characters valid in english, hoping MySQL won't barf spetacularly on them.

Most weirdly, the fact that the default collation is SWEDISH. It is a complete freak show,

Unless you're Swedish, I imagine. Then it's quite handy.

I believe the author of MySQL was Swedish, so to me it all makes sense. It also provides a learning opportunity for people who believe the entire planet operates on ASCII.

Re: Time for a WTF MySQL Moment

#73

Post by ranieuwe »

speeder wrote: post #62
kochthesecond wrote: post #42

Earlier quoted context omitted.

Nice These three points has made me raving mad from working with mysql: - The default 'latin1' character set is in fact cp1252, not ISO-8859-1, meaning it contains the extra characters in the Windows codepage. 'latin2', however, is ISO-8859-2. - The 'utf8' character set is limited to unicode characters that encode to 1-3 bytes in UTF-8. 'utf8mb4' was added in MySQL 5.5.3 and supports up to 4-byte encoded characters.…

I am currently trying to fix a program that was made by a person that didn't knew those details of MySQL... Most weirdly, the fact that the default collation is SWEDISH. It is a complete freak show, the users kinda got used to it, butchering our language (portuguese) to use only characters valid in english, hoping MySQL won't barf spetacularly on them.

MySQL being a Swedish company, the default collation for MySQL was (is?) latin1_swedish_ci.

Re: Time for a WTF MySQL Moment

#74

Post by erik_seaberg »

Sebb767 wrote: post #18
falcolas wrote: post #8

Earlier quoted context omitted.

> "this is highly unexpected behaviour" The behavior in question is having an upper and lower bound on a time interval. This strikes me as highly expected behavior. The maximum on the interval is lower than the author expected; and reading the docs quickly cleared up what the interval maximum is. The entire rant boils down to "MySQL's choice to keep backwards compatibility is stupid, because I think this interval lim…

I agree it's not a necessary change. But, on the other hand, how much compatibility would it really break? I cannot imagine much applications are dependent on MySQL throwing an error at 800-odd hours (and it would arguably be a very strange design decision).

MySQL is notorious for quietly guessing what you must have meant. Writers need to validate up front, and then try to read back what was actually written.

Re: Time for a WTF MySQL Moment

#76

Post by munk-a »

benesch wrote: post #44
munk-a wrote: post #19

I'm a big fan of Postgres too for a number of reasons, but this issue is pretty clearly documented so I'd like to counter with an issue I hit in Postgres recently that is terribly documented. UNNEST works a bit funky, and in particular it works super funky if you have multiple calls in the same select statement (or any set expanded function calls it turns out). There's a bit of a dive into here[1] (though that is out…

> I hit in Postgres recently that is terribly documented. I'm going to have to disagree with you there. This issue is quite well documented in the "SQL Functions Returning Sets" section [0]. The relevant bit starts thusly: > ...Set-returning functions can be nested in a select list, although that is not allowed in FROM-clause items. In such cases, each level of nesting is treated separately, as though it were a separ…

I hadn't seen the index - that's neat.

In terms of the documentation quality I do agree that it's documented but not obviously, you mentioned that it's in the "SQL Functions Returning Sets" section however this section isn't indicated to by the Array functions and operators page - additionally while, if you know that you're dealing with an issue related to SRFs it's pretty easy to find - attempting to get at that information via google isn't going to get you anything unless you specifically hone in on set returning functions. I ended up finding that doc page after finding a SO answer that mentioned SRFs while searching for "postgres unnest cartesian product".

The information is in the documentation, but the documentation isn't always super good at linking to other relevant portions of the documentation and, honestly, reading the documentation about the feature you need is reasonable, but I don't expect most people are reading the full postgres docs before starting to play around with it. So I don't disagree that the information is there, but I do think it is mostly inaccessible due to the structure of the documentation.

Re: Time for a WTF MySQL Moment

#77

Post by rdiddly »

masklinn wrote: post #48
meritt wrote: post #45

Earlier quoted context omitted.

Edit. Fuck HN.

> Maybe you should take a moment to review the etiquette you're trying to hypocritically enforce. Although they did breach it, they did not invoke the etiquette, they only made a more general recommendation of calming down (however snarkily). You, however, are invoking the etiquette while breaching multiple items from it in your original comment.

Guilty as charged; if I could still edit it, I might remove the word "butthurt."

Re: Time for a WTF MySQL Moment

#79

Post by nytgop77 »

falcolas wrote: post #23
Sebb767 wrote: post #18

Earlier quoted context omitted.

I agree it's not a necessary change. But, on the other hand, how much compatibility would it really break? I cannot imagine much applications are dependent on MySQL throwing an error at 800-odd hours (and it would arguably be a very strange design decision).

> how much compatibility would it really break Probably only a few applications; but that's still too many. And backwards compatibility does matter. A change here means that some few dozen developers have to now troubleshoot a previously-stable application which now fails silently in odd corner cases.

then create new type. time2 or datetime13 with improved behaviour and say in docs to prefer newer unless your specicaly know that you need old behaviour.

Re: Time for a WTF MySQL Moment

#80

Post by Roboprog »

simias wrote: post #21

> This format is even less wieldy than the current one, requiring multiplication and division to do basically anything with it, except string formatting and parsing – once again showing that MySQL places too much value on string IO and not so much on having types that are convenient for internal operations and non-string-based protocols. Not necessarily an odd choice in the Olden Days, after all BCD representation us…

https://en.wikipedia.org/wiki/Binary-coded_decimal#Packed_BC...

Earlier than the 60s. Had to work on a system in the 90s to “transpile” IBM minicomputer code to C.

Useful for accounting since what you see is what you get as far as cents and other decimals go. 1/5, and thus 1/10, can only be approximated in floating point.

Not that I’m defending MySQL

Post reply on HN