On Fri, Dec 7, 2018 at 3:50 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2018-Dec-07, Robert Haas wrote:
> > More generally, whether or not we should "keep something away from our
> > users" really depends on how likely the upsides are to occur relative
> > to the downsides. We don't try to keep users from running DELETE
> > because they might delete data they want; that would be nanny-ism.
> > But we do try to keep them from reading dirty data from an uncommitted
> > transaction because we can't implement that without a risk of server
> > crashes, and that's too big a downside to justify the upside. If we
> > could do it safely, we might.
> >
> > From that point of view, this is doubtless not the worst feature
> > PostgreSQL will ever have, but it sure ain't the best.
>
> Well, look at this from this point of view: EnterpriseDB implemented
> this because of customer demand (presumably). Fujitsu also implemented
> this for customers. The pgjdbc driver implemented this for its users.
> Now 2ndQuadrant also implemented this, and not out of the goodness of
> our hearts. Is there any room to say that there is no customer demand
> for this feature?
There is no room at all for doubt on that point. The issue, at least
IMV, is collateral damage -- customers surely want it. Indeed, if
we'd been smarter, maybe we would've invented a way to make it work
like that from the beginning. But changing it now, even as an optional
behavior, will (as Tom and Andres are rightly saying) mean that every
tool and extension author potentially has a problem with things not
working as expected. One can make an argument that such pain is worth
enduring, or that it isn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company