| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)mail(dot)com> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: TRUNCATE SERIALIZABLE and frozen COPY |
| Date: | 2012-11-09 16:00:34 |
| Message-ID: | CA+U5nMLuLN6JW300wzrAcbmzLsDaP9b1BOvqsBKA6Fv1VXYPrA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9 November 2012 15:46, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Altering TRUNCATE so it behaves perfectly from an MVCC/Serializable
> perspective is a much bigger, and completely different goal, as well
> as something I don't see as desirable anyway for at least 2 good
> reasons, as explained. IMHO if people want MVCC/Serializable
> semantics, use DELETE, possibly spending time to make unqualified
> DELETE do some fancy TRUNCATE-like tricks with relfilenodes.
We spent a lot of time in 9.2 making TRUNCATE/reload of a table "just
work", rather than implementing a REPLACE command.
ISTM strange to throw away all that effort, changing behaviour of
TRUNCATE and thus forcing the need for a REPLACE command after all.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2012-11-09 16:03:05 | Re: TRUNCATE SERIALIZABLE and frozen COPY |
| Previous Message | Simon Riggs | 2012-11-09 15:46:13 | Re: TRUNCATE SERIALIZABLE and frozen COPY |