On 12/7/18 12:50 PM, Alvaro Herrera 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?
Amazon also implemented something similar for the database migration
tool. I am unsure if they do it similarly with the DMS. With the DMT it
definitely had the XID issue that some are concerned with but I would
argue that is the cost of doing business.
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
*** A fault and talent of mine is to tell it exactly how it is. ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
***** Unless otherwise stated, opinions are my own. *****
