3 ms·

I ran into some scaling challenges with Postgres a few years ago and had to dive into the docs. While I was mostly living out of the "High Availability, Load B

• jbverschoor 2y ago
  Like many of the BSDs
  • aerzen 2y ago
    Did Postgres used to be a BSD? Are they known for good documentation?
    • password4321 2y ago
      BSD? No, that's operating system(s) Good documentation? Yes
    • andrewf 2y ago
      BSD was the Unix distribution; BSD and Postgres/Ingres development did overlap at UC Berkeley.
• danpalmer 2y ago
  They are excellent! Another great example is the Django project, which I always point to for how to write and structure great technical documentation. Working with Django/Postgres is such a nice combo and the standards of documentation and community are a huge part of that.
  • irjustin 2y ago
    Interestingly I have had almost the exact opposite experience being very frustrated with the Django docs. To be fair, it could be because I'm frustrated with Django's design decisions having come from Rails. When learning Django a few years ago, I still carry a deep loathing against polymorphism (generic relations[0]), and model validations (full clean[1]), You know what - it's design decisions... [0] https://docs.djangoproject.com/en/5.1/ref/contrib/contenttypes/ https://docs.djangoproject.com/en/5.1/ref/contrib/contenttyp... [1] https://docs.djangoproject.com/en/5.1/ref/models/instances/#validating-objects https://docs.djangoproject.com/en/5.1/ref/models/instances/#...
    • rtpg 2y ago
      generic relations are hard to get right, really if you can avoid using them you're going to avoid a lot of trickiness. When you need them... it's nice to have them "just there", implemented correctly (at least as correctly as they can be in an entirely generic way). Model validations is a whole thing... I think that Django offering a built-in auto-generated admin leads to a whole slew of differing decisions that end up coming back to be really tricky to handle.
    • globular-toast 2y ago
      Would love to hear more about what you don't like with model validations (full clean).
      • irjustin 2y ago
        Sorry on the slow reply. But yea, I can complain at length. - Model validations aren't run automatically. Need to call full_clean manually. - EXCEPT when you're in a form! Forms have their own clean, which IS run automatically because is_valid() is run. - This also happens to run the model's full_clean. - DRF has its own version of create which is separate and also does not run full_clean. - Validation errors in DRF's Serializers are a separate class of errors from model validations and thus model Val Errors are not handled automatically. - Can't monkey patch models.Model.save to run full_clean automatically for because it breaks some models like User AND now it would run twice for Forms+Model[0]. Because of some very old web-forum style design decisions, model validations aren't unified thus the fragmentation makes you need to know whether you're calling .save()/.create() manually, are in a form, or in DRF. And it's been requested to change this behavior but it breaks backwards compat[0]. It's frustrating because in Rails this is a solved problem. Model validations ALWAYS run (and only once) because... I'm validating the model. Model validations == data validations which means it should be true for all areas regardless of caller, except in exceptions, then I should be required to be explicit when skipping (i.e. Rails) where as in Django I need to be explicit in running it - sometimes... depends where I am. [0] https://stackoverflow.com/questions/4441539/why-doesnt-djangos-model-save-call-full-clean https://stackoverflow.com/questions/4441539/why-doesnt-djang...