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. *****
