11–20 of 37 posts
Which is a mixed blessing; Aurora sounds great, but I was looking forward to getting back into PG after years of RDS being MySQL-only.
When I saw this was a PHP project: https://dl.dropboxusercontent.com/u/31250/gifs/no-thanks.gif
When I saw this was a PHP project: https://dl.dropboxusercontent.com/u/31250/gifs/no-thanks.gif
Fortunately there was a project that reimplemented many of these functions in Postgres:
A big problem I've encountered was MySQL-specific functions used in client code. Fortunately there was a project that reimplemented many of these functions in Postgres: https://github.com/pornel/mysqlcompat
A big problem I've encountered was MySQL-specific functions used in client code. Fortunately there was a project that reimplemented many of these functions in Postgres: https://github.com/pornel/mysqlcompat
There was but the last commit is from 2011?
The code is even older, but fortunately the most common MySQL functions haven't changed in maybe a decade.
When I saw this was a PHP project: https://dl.dropboxusercontent.com/u/31250/gifs/no-thanks.gif
Really? What does the language it's written in have to do with anything at all here?
Earlier quoted context omitted.
Ah. That's a relief, I was a little worried. But that makes it strange that someone, knowing of this limitation, would choose to start with the xml dump format.
I think the fact that this form of dump doesn't contain foreign keys is even more extraordinary. What's the point of having a dump format that you can't use to restore your database properly? Does it have a health warning advising that it's not a proper dump?
You get this:
CONSTRAINT `fk_courses_offered_class_details`
FOREIGN KEY (`course_id`)
REFERENCES `courses_offered` (`id`)