Steve Singer <ssinger_pg at sympatico.ca> writes:
> On Mon, 5 Apr 2010, Jaime Casanova wrote:
>> well my main preocupation is to avoid developers to execute truncate,
>> but maybe the answer is to revoke that privilege in 8.4
>
> You could maybe also accomplish this by installing your own TRUNCATE
> trigger that prevents the truncate with an error.
>
> At some point some thought/discussion should be put into the best way
> of adding truncate support to some future slony version.

Simon Riggs did up a sample of how this might be done, shortly after he
implemented TRUNCATE triggers.

http://lists.slony.info/pipermail/slony1-patches/2008-January/000034.html

He took the approach of capturing the event in sl_log_*, so that
  I=Insert
  U=Update
  D=Delete
gets augmented with
  T=Truncate

The dangerous thing, to my mind, is that there's a further ordering
issue that would be needed.

Supposing, for instance, there's a mutual foreign key dependancy, the
processing of these might require either:
  a) Specifying multiple tables in the truncate request, or
  b) CASCADE

There are several possible implementation choices, most of them fairly
dangerous.  If anything goes wrong, then either:

 a) You've deleted a big pile of data on the replica that shouldn't be
    gone, or

 b) The TRUNCATE on the replica fails, and replication ceases until
    someone does some "surgery" to rectify things (e.g. - removing
    troublesome entries from sl_log_[12], and doing the right truncate
    "by hand," though I could see it being worse still :-().

A "safe" answer, I suppose, is to put the "denyaccess" trigger on the
TRUNCATE action.

It would be a good thing to have a coherent writeup of a concrete
proposal of intent.  Implementation's not important, just to describe
the intended semantics in some detail.
-- 
(reverse (concatenate 'string "ofni.sailifa.ac" "@" "enworbbc"))
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"