Tom Lane <t...@sss.pgh.pa.us> writes: > Completely. This is a user-visible behavior that we have encouraged > people to rely on, and for which there is no easy substitute.
Excited to have self-healing tables (against bloat), I parse this as an opening. Previously on this thread you say: > (Actually, the ctid is only being used for fast access here; the xmin > is what is really needed to detect that someone else updated the row. > But the proposed tuple-mover would break the xmin check too.) So to have the impossible feature, we need a way not to break existing code relying on ctid and xmin. How stretching would you consider the idea of taking a (maybe new) table lock as soon as a SELECT output contains system columns, this lock preventing the magic utility to operate? Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
