On Wed, Mar 21, 2012 at 8:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Oh, right. So scratch that objection. The other one is still fatal > though ...
So, could we just decide that we don't care about preserving that property any more, and document it as an incompatibility in whatever release we break it in? It strikes me that it likely wouldn't be any worse than, oh, say, flipping the default value of standard_conforming_strings, and we could even have a backward compatibility GUC if we were so inclined. I realize that the standard_conforming_strings change was dictated by a desire to conform to the SQL standards, and this isn't, but it seems awfully painful to me to insist that this is a property that we can never give up. I can remember one other proposal to which you raised this same objection: the idea of an on-line tuple mover to handle the situation where a user wishes to do an on-line reorganization of a bloated table by incrementally moving tuples to lower-numbered pages. It's possible that the idea with which I started this thread might turn out to be horribly unsafe for one reason or another, but I think that there's broad support for the tuple mover concept. -- 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
