You disagree that many, if not most, organizations are plump with multiple layers of ineffective management?
At 42, I can tell you it gets worse. The idiocy of management is boundless, as is their energy in pushing their ideas and their inability to absorb any information.
Yes, I've had the misfortune to hear countless client complaints resulting from their failure to lower the TTL well in advance of a planned DNS change on a key host.
In summary - once the DNS information is changed in the database, the DNS server continues to serve out stale information for the next 10,000+ queries.
We don't know that he wasn't granted lenience, the case never even went to trial.
Yes, because Microsoft is barely breaking even.these days.
Are you paying attention? We're talking about usable output above 22k. A 3dB rolloff at 15k is going to be what at 22k?
But what's the upper frequency cutoff of the speaker?
You may have better luck with a script designed specifically to convert mysql to pg. We use one as part of our ora to PG migration project (ora2pg). It's not perfect but it works pretty well. A quick search showed a couple of options for mysql, maybe something like http://sourceforge.net/projects/mysql2pg/ would give you better luck. pg_dump isn't much better at bringing in dumps than psql is. These dedicated conversion scripts usually take advantage of perl DBI connectivity to both DBs simultaneously, versus trying to export ddl and sql, and it seems to be a more successful approach.
Yeah guy, you schooled me. You can't write a script to make those seemingly-minor tweaks to the mysqldump output? FWIW psql can barely import PG's own dumps. I think in the realm of rdmbs you'll find that product A's software for outputting to product B's import format is _always_ at least slightly broken.
The problem is that database abstraction (at the level sufficient to throw a switch to change DB platforms) carries a performance price. If you've scaled your business to the point that you "need" SQL Server (as if it outperforms mysql), as the OP was suggesting, you have probably de-abstracted yourself to the point that swapping DBs will be a serious pain.
"Issues with double quotes vs single quotes vs ticks" = someone writing code in 2013 that isn't using bound parameters.