Re:Introduction to Hacking PostgreSQL (2007)
by parhamn on Friday April 10, 2020 @09:22PM
(#22839003)
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]
Re:Introduction to Hacking PostgreSQL (2007)
by lfittl on Friday April 10, 2020 @11:45PM
(#22839508)
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.
Re:Introduction to Hacking PostgreSQL (2007)
by uhoh-itsmaciek on Saturday April 11, 2020 @03:16AM
(#22840155)
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.
Re:Introduction to Hacking PostgreSQL (2007)
by ccleve on Friday April 10, 2020 @10:21PM
(#22839207)
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.
Re:Introduction to Hacking PostgreSQL (2007)
by mettamage on Wednesday April 15, 2020 @07:00AM
(#22876370)
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 :)
Re:Introduction to Hacking PostgreSQL (2007)
by ghayes on Friday April 10, 2020 @08:56PM
(#22838872)
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.
[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.
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.
Since I couldn't find your email, I'd like to thank you like this :)