On Wed, Mar 14, 2012 at 6:10 PM, Noah Misch <n...@leadboat.com> wrote: >> Well, post-release, the cat is out of the bag: we'll be stuck with >> this whether the performance characteristics are acceptable or not. >> That's why we'd better be as sure as possible before committing to >> this implementation that there's nothing we can't live with. It's not >> like there's any reasonable way to turn this off if you don't like it. > > I disagree; we're only carving in stone the FOR KEY SHARE and FOR KEY UPDATE > syntax additions. We could even avoid doing that by not documenting them. A > later major release could implement them using a completely different > mechanism or even reduce them to aliases, KEY SHARE = SHARE and KEY UPDATE = > UPDATE. To be sure, let's still do a good job the first time.
What I mean is really that, once the release is out, we don't get to take it back. Sure, the next release can fix things, but any regressions will become obstacles to upgrading and pain points for new users. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
