-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support PostgreSQL #221
Support PostgreSQL #221
Conversation
1583341
to
93b73bb
Compare
fdf4775
to
eebae88
Compare
Stumbled over lib/pq#1006. @Thomas-Gelf Have you ever seen any customers insisting on TLS between app and DB? |
There are some with such policies in place. Usually the wording is not "the DB connection must use TLS", it's more like "the connection to databases or similar services must be encrypted". Policies vary depending on the kind of data being stored. As Custom Vars in the IcingaDB might carry secrets, we usually fall in the "sensible" class. While TLS is fine for daemons, it is annoying for the web because of the additional latency - "per click". Workarounds include local DB proxies then talking encrypted to the DB or IPSEC as a transport. Often you can also compile a form and check the "not yet, but soon" option 😆 Long story short: yes. And they're probably getting more. |
Thanks, good to know. Cool that we don't have to support TLS directly. |
IMHO that shouldn't be the conclusion :D In every project where we didn't offer TLS for DB connections we got issues complaining about that. Therefore I'd strongly suggest to offer it, especially for new projects. Eventually we should not only offer it everywhere, but lead by example - and strongly recommend it for every setup and configuration. |
d4f639c
to
c1c804c
Compare
As the tests show, it works... theoretically: lib/pq#1007 |
State: Waiting for feedback from @lippserd |
What's the status on this issue? Really would love to see postgres support in next release |
By the way avoid duplicate rows in the same upsert chunk to avoid Postgres error 21000 (ON CONFLICT DO UPDATE command cannot affect row a second time). refs #136
not to require web to LOWER(). refs #136
Before: idb=# select * from icingadb_instance where responsible = 'y'; ERROR: operator does not exist: boolenum = unknown LINE 1: select * from icingadb_instance where responsible = 'y'; ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. idb=# refs #136
PostgreSQL does not allow null bytes in varchar, char and text fields.
76b447b
to
b2618de
Compare
Full ack. MySQL *nix socket support lack makes this a classic case of other construction area :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a note to my future self or anyone else coming back to this PR asking who approved this: I still don't think these boolenum
and *uint
types in the schema are a good idea but I was outvoted there.
Just for the records, what would you propose? |
The standard But anyways, I didn't want to resume that discussion, GitHub just doesn't allow to get rid of the "changes requested" state without explicit approval. |
fixes #136