From my limited experience diving into the Postgres source code, it's really a treat. Everything is very clearly written and documented. It's pretty easy to read the source code to get an understanding of how components of Postgres work under the hood.
Thank you. If you know of any other resources like this, please post them.
I spent a few hours looking for tutorials, examples, etc. and I didn't find much. I found it difficult to figure out how to set up a proper IDE and do simple debugging. It's not trivial.
Hey unrelated, but I wanted to thank you for your Udacity post on dynamic programming. It is one of the few examples that gives a ton of exercises that does not use recursion and memoization but rather uses an iterative approach.
Since I couldn't find your email, I'd like to thank you like this :)
It's a shame you can't easily add an extensions to most hosted postgres solutions. I hacked on the postgres ltree extension [1] recently, and was amazed at how easy it is to extend functionality of the database, add new types/operators/etc. I think if they were a bit more accessible we'd see them much more. You can even write them in go [2]
I agree re: your comment on hosted provider support. Extensibility is a major benefit of Postgres, and there is a lot more untapped potential (e.g. even just for custom data types), if only major providers supported it better.
FWIW, from having looked into this, there are two main challenges:
(1) Security - How to avoid the customer becoming superuser by using specifically crafted extensions. In practice this is mostly a defense in depth scenario, since you're running inside a VM already anyway.
(2) Maintenance / Support / SLA - If customers load a broken extension and that causes the server to crash, does the provider still give an SLA? Where to draw the line / how to evaluate this when support tickets get opened?
Both of these could be solved (I think) if there was a better sandboxing mechanism.
Really the issue here is that once you're at the C extension / shared library level, you can do pretty much anything, and thats really hard to support as a Database-as-a-service provider.
Right. Plus (which you sort of hint at under Maintenance), packaging of more elaborate extensions like PostGIS was a nightmare, especially with respect to upgrades (the situation is better now). And under Security, it's not just worrying about users trying to escape your sandbox: it's also making sure they don't leave themselves open to exploits from their users.
12 comments
[ 4.1 ms ] story [ 25.9 ms ] threadI spent a few hours looking for tutorials, examples, etc. and I didn't find much. I found it difficult to figure out how to set up a proper IDE and do simple debugging. It's not trivial.
Since I couldn't find your email, I'd like to thank you like this :)
[1] https://github.com/postgres/postgres/tree/master/contrib/ltr...
[2] https://github.com/microo8/plgo
FWIW, from having looked into this, there are two main challenges:
(1) Security - How to avoid the customer becoming superuser by using specifically crafted extensions. In practice this is mostly a defense in depth scenario, since you're running inside a VM already anyway.
(2) Maintenance / Support / SLA - If customers load a broken extension and that causes the server to crash, does the provider still give an SLA? Where to draw the line / how to evaluate this when support tickets get opened?
Both of these could be solved (I think) if there was a better sandboxing mechanism.
Really the issue here is that once you're at the C extension / shared library level, you can do pretty much anything, and thats really hard to support as a Database-as-a-service provider.