Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Murmur postgresql support #2541
This pull request uses the UPSERT functionality of PostgreSQL. If QPSQL is chosen as the database engine in mumble-server.ini then the version of PostgreSQL used needs to be 9.5 or higher.
Key changes this pull request makes:
Example settings for mumble-server.ini to use PostgerSQL:
These settings will cause murmur to try and connect to a PostgreSQL database called "localdb" on the server with the address "localhost" and port 5432.
I made a mess of my old branch and the rebasing onto all the new commits seemed to make the commit sequence look weird. To fix that I made a new branch and manually did all the edits and commits in sequence. Hopefully all's well with this one. I think I've addressed most of the issues raised about the last pull request.
The only things I'm not sure about are the lines
I've closed #2383 as this is the new improved version.
I noticed that most of the tables created by murmur in PostgreSQL don't actually have primary keys. It seems a bit odd. I was surprised that the UPSERT was working without the PKEYs being present, and that I didn't need to add a bunch of alter table statements in different places to add unique constraints to trigger the conflicts so that the UPSERT would update instead of insert duplicates like:
Seems the indexes served that purpose however as I didn't need to add the above bits to get it to work.
Thanks a bunch for doing this.
I haven't looked closely yet... Just a few drive-by comments.
Hmmm. Seems odd.
Yup == not != , copy and paste error in the comment :)
Regarding the PKEYs on the tables, these tables have them:
And these do not:
Attached is a zip file containing text files with SQL commands which would result in same tables that murmur makes in PostgreSQL (I copied them from the table SQL pane in pgAdmin3)
Edit: It seems the job of the PKey is kinda being done with unique indexes in those tables.
Are there any more changes that need to be made? After this next week I'm not sure when I'll get the time to look at this again.
If you're suggesting replacing instances of SQLQUERY(x) with SQLDO(x) then that won't work.
In PostgreSQL PREPARE may only appear before
I suppose it might be clearer if exec was renamed prepAndExec or something, and then query was renamed to exec.
I meant this week, really just the next 5 days actually.