On 10 September 2012 17:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The point of the proposal that I am making is to have a simple,
> low-maintenance solution for people who need a single-application
> database. A compromise somewhere in the middle isn't likely to be an
> improvement for anybody. For instance, if you want to have additional
> connections, you open up a whole collection of communication and
> authentication issues, which potential users of a single-application
> database don't want to cope with.
So the proposal is to implement a database that can't ever have 2 or
more connections. And so any data it stores cannot ever be accessed by
another connection, so all forms of replication are excluded and all
maintenance actions force the database to be unavailable for a period
of time. Those two things are barriers of the most major kind to
anybody working in an enterprise with connected data and devices. The
only people that want this are people with a very short term view of
the purpose of their applications, and disregard for the value and
permanence of the data stored. They may not want to cope with those
issues *now* but they will later and won't thank us for implementing
it in a way that means it can never be achieved.
To be honest, I can't believe I'm reading this.
And worse, it's on our Don't Want list, and nobody has said stop.
It's almost impossible to purchase a CPU these days that doesn't have
multiple cores, so the whole single-process architecture is just dead.
Yes, we want Postgres installed everywhere, but this isn't the way to
achieve that.
I agree we should allow a PostgreSQL installation to work for a single
user, but I don't see that requires other changes. This idea will
cause endless bugs, thinkos and severely waste our time. So without a
much better justification, I don't think we should do this.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services