On 29 October 2012 12:27, Andres Freund <and...@2ndquadrant.com> wrote:
>> This sounds like we need a GUC or table-level default to control >> whether FOR UPDATE means FOR UPDATE or FOR DELETE > > I don't like adding a new guc for something that should be solveable with some > creative naming. If a new user doesn't get a bit more concurrency due to > manually issued 9.2 FOR UPDATE implicitly being converted into a FOR NO KEY > UPDATE its not too bad. The code needs to be checked whether thats valid > anyway. The reverse is not true... The main point here is that introducing new non-optional behaviour is a compatibility problem and we shouldn't rush that. If we decide to change FOR UPDATE to mean FOR NO KEY UPDATE that needs separate consideration and shouldn't happen until sometime after the feature goes in (months, or perhaps releases). We're introducing a new feature that will allow us to avoid lock problems, by taking the current FOR UPDATE behaviour and splitting it into two options: one weaker and one stronger. We need explicit names for both of those options. The most obvious naming is FOR [[NO] KEY] UPDATE Don't much like that, but its pretty unambiguous and fairly neat. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
