4 ms·

Again, not sure what you’re talking about here. `pg_hba.conf`? Normally you don’t need to modify that regularly (if ever). Normal access control can be done wi

by mikl 4y ago

Again, not sure what you’re talking about here. `pg_hba.conf`? Normally you don’t need to modify that regularly (if ever). Normal access control can be done with GRANTs, just like MySQL or Oracle. As for streaming replication, that was added in PostgreSQL 9.0, six major versions ago. Sure, it was late to the party, but it’s not exactly a recent addition.

throwaway67743 4y ago
Ah for some reason I can reply now: Regardless being 2 decades late to the party is unacceptable - it's still not complete and makes real world management a chore, I still admire the purist attitude it has its place but you can't also then claim it's a useful competitor - which is what they do. Unfortunately it's a perl postgres vs the world thing - both are irrelevant.
- mikl 4y ago
  That they were late to the party doesn’t really matter _now_. It might have mattered five years ago. As for the config, one might argue that reconfiguring replication isn’t a common task, usually something you do when setting up the cluster and never mess with again. I understand that there are pain points running PostgreSQL at massive scale. But 99.9% of projects needing a database never reach that scale. And once they do, they probably need to re-engineer big chunks of the application anyway.
  - throwaway67743 4y ago
    Well this is one aspect - application should not have to care about underlying db topology - if it does then the db is wrong, my main issue tbh is that other databases implement the inevitable like proxying or sharing while postgres leaves it to horrific perl scripts from the last century, it's really not admissable as a production solution
    - pritambaral 4y ago
      > while postgres leaves it to horrific perl scripts from the last century Your knowledge of what Postgres supports and how to administrate it seems to be a few years out of date. There's plenty of examples in this thread alone.
pritambaral 4y ago
> PostgreSQL 9.0, six major versions ago Correction: thirteen major versions ago, approx. thirteen years ago. 9.x were all major releases.

by mikl 4y ago

throwaway67743 4y ago

Ah for some reason I can reply now: Regardless being 2 decades late to the party is unacceptable - it's still not complete and makes real world management a chore, I still admire the purist attitude it has its place but you can't also then claim it's a useful competitor - which is what they do. Unfortunately it's a perl postgres vs the world thing - both are irrelevant.

mikl 4y ago
That they were late to the party doesn’t really matter _now_. It might have mattered five years ago. As for the config, one might argue that reconfiguring replication isn’t a common task, usually something you do when setting up the cluster and never mess with again. I understand that there are pain points running PostgreSQL at massive scale. But 99.9% of projects needing a database never reach that scale. And once they do, they probably need to re-engineer big chunks of the application anyway.
- throwaway67743 4y ago
  Well this is one aspect - application should not have to care about underlying db topology - if it does then the db is wrong, my main issue tbh is that other databases implement the inevitable like proxying or sharing while postgres leaves it to horrific perl scripts from the last century, it's really not admissable as a production solution
  - pritambaral 4y ago
    > while postgres leaves it to horrific perl scripts from the last century Your knowledge of what Postgres supports and how to administrate it seems to be a few years out of date. There's plenty of examples in this thread alone.

pritambaral 4y ago

> PostgreSQL 9.0, six major versions ago Correction: thirteen major versions ago, approx. thirteen years ago. 9.x were all major releases.