On Mon, Jan 2, 2017 at 8:03 PM, Lewis, Ian (Microstar Laboratories) <ile...@mstarlabs.com> wrote: > Personally, I believe such an option would increase, not decrease the > number of people who could relatively easily use PostgreSQL. If that is > right it is a strong argument for such a modal behavior in spite of the > obvious real pain.
That is definitely true. "X will let more people easily use PostgreSQL" is an argument with a lot of merit, and I don't see how anyone could argue otherwise (unless they want fewer people to use PostgreSQL). I think the issue isn't so much whether we'd increase or decrease the number of people who could easily use PostgreSQL; I'm confident that, as you say, many potential users would find it convenient. The issue is, rather, that every extension written for PostgreSQL, whether in or out of core, needs to handle this issue and every general-purpose client tool (pgAdmin, etc.) needs to be aware of it. Many drivers probably need to know about it. Any application built on PostgreSQL must either now require a specific server configuration or be prepared to work with any of them. I think this is the sort of thing where the server changes would take a month and tools, connectors, and extensions would still be getting bug reports a decade later. Now, I am not as convinced as Tom is that this is a categorically terrible idea. But I do think that it would be easy to underestimate the amount of collateral damage that such a change would cause. It would be very large. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
