6 ms·

Introduction to Hacking PostgreSQL (2007)

• robolange 6y ago
  Interesting, but shouldn't this be labeled 2007?
  • dang 6y ago
    Added. Thanks!
• intrd 6y ago
  What a gem, thank u :)
  • eddieoz 6y ago
    GEM was a very famous j-pop group, but they stopped to act 2 years ago.
• ghayes 6y ago
  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.
• ddlutz 6y ago
  There's an edX MOOC of a similar title that people here may also may be interested in: https://www.edx.org/course/hacking-postgresql-data-access-methods https://www.edx.org/course/hacking-postgresql-data-access-me...
  • ccleve 6y ago
    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.
    • ddlutz 6y ago
      while not specific to postgres, for general DB internals the CMU courses are top-notch. intro: https://15445.courses.cs.cmu.edu/fall2019/ https://15445.courses.cs.cmu.edu/fall2019/ advanced: https://15721.courses.cs.cmu.edu/spring2020/ https://15721.courses.cs.cmu.edu/spring2020/
      • mettamage 6y ago
        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 :)
• parhamn 6y ago
  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] [1] https://github.com/postgres/postgres/tree/master/contrib/ltree https://github.com/postgres/postgres/tree/master/contrib/ltr... [2] https://github.com/microo8/plgo https://github.com/microo8/plgo
  • lfittl 6y ago
    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.
    • uhoh-itsmaciek 6y ago
      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.