DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=DKryCbRV5PX0O8S/5vM0NBTQml7zdm9A+QVE5jeiyKxnQjPWtB3fTxMiVqHNsJPvJrxFBJN1CuNlECATFwzLzniXNlBpxGe/cPfPgQaxHow6qziEsSs35VVfRl92yudi1zM+vAOP6n2uIeWO/Zykvgg4scxWbHJntEU3KZYYuCc=;
Date: Mon, 28 Jan 2008 20:40:11 -0800 (PST)
From: chester c young <chestercyoung@yahoo.com>
Subject: Re: Proposed archival read only trigger on rows - prevent history
	modification
To: Bryce Nesbitt <bryce1@obviously.com>
Cc: sql pgsql <pgsql-sql@postgresql.org>
In-Reply-To: <479EA8A3.5070401@obviously.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <771732.23057.qm@web54301.mail.re2.yahoo.com>


> I'm considering building a protective mechanism, and am seeking
> feedback
> on the idea.  The approach would be to add a new column named "ro" to
> each table at invoice level and below.  Then have a trigger on
> 'ro'==true deny the write, and probably raise a huge stink.  As
> invoice
> are mailed each month, all the supporting data would be set to "ro"
> true.

instead of triggers I use update-able views and permissions.

1. all dml goes through the view
2. use rules on the view to do dml to the table
3. in rules prevent updating all/any columns when whatever
4. grant dml to view to your pgconnect user
5. revoke dml from table to your pgconnect user

imho another instance where rules rule.  for example, you can easily
fit logging into the same view.


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs