4 ms·

Replication support has been a big issue with Postgres in the past, with folks needing third party proxies that were clumsy to use to accomplish it. This improv

by astine 17y ago

Replication support has been a big issue with Postgres in the past, with folks needing third party proxies that were clumsy to use to accomplish it. This improvement is big news. It sounds like there are a lot of improvements with this release of Postgres, and that they are taking a less conservative approach to development than they have in the past; I hope that they won't sacrificed stability too much to accomplish this.

crad 17y ago
I'm not sure what you base the less conservative approach to development comment on. As far as I know, the development process and patch application process is the same as it has been in recent years. Stability and quality of code are still #1. Edit: clarified the conservative approach to development.
- mahmud 17y ago
  Perhaps the submission itself? From the first paragraph: "While past major releases have been quite conservative in their scope, this release shows a bold new desire to provide facilities that every new and existing user of PostgreSQL will embrace."
  - crad 17y ago
    The intent was not to speak to the development process per se, but the roadmap for Postgres.
    - astine 17y ago
      I think you misunderstand me I don't mean to imply that the Postgres developers have decided to be sloppier in their development practices or anything like that. When I say 'less conservative in development' I mean that scope is an aspect of development. When a project's scope increases, so does it's workload and complexity; a development team can either allocate more resources and time to the project or let quality slide. This is a truism and I mean no slight to the Postgres people who, in my experience have consistently delivered a very stable project to date and may very well be able to handle a broader scope with no loss in quality.

4 ms·

Replication support has been a big issue with Postgres in the past, with folks needing third party proxies that were clumsy to use to accomplish it. This improv

by astine 17y ago

crad 17y ago
I'm not sure what you base the less conservative approach to development comment on. As far as I know, the development process and patch application process is the same as it has been in recent years. Stability and quality of code are still #1. Edit: clarified the conservative approach to development.
- mahmud 17y ago
  Perhaps the submission itself? From the first paragraph: "While past major releases have been quite conservative in their scope, this release shows a bold new desire to provide facilities that every new and existing user of PostgreSQL will embrace."
  - crad 17y ago
    The intent was not to speak to the development process per se, but the roadmap for Postgres.
    - astine 17y ago
      I think you misunderstand me I don't mean to imply that the Postgres developers have decided to be sloppier in their development practices or anything like that. When I say 'less conservative in development' I mean that scope is an aspect of development. When a project's scope increases, so does it's workload and complexity; a development team can either allocate more resources and time to the project or let quality slide. This is a truism and I mean no slight to the Postgres people who, in my experience have consistently delivered a very stable project to date and may very well be able to handle a broader scope with no loss in quality.