On 2/13/2006 9:57 AM, Christopher Browne wrote:

> A way to do this that would be, oh, call it "forcibly robust" would be
> for each SYNC to check to see if pg_shadow had changed, and update the
> user table correspondingly.
> 
> In practice, it's probably good enough to have some script that runs
> every so often to look for changes.  I know we don't modify pg_shadow
> on our systems so often as every week; polling for it once a day would
> likely suffice, for us...

A DB user per application user is IMHO broken design. That said, it 
could be done the other way around. Have a regular, replicated table 
with the same structure as pg_shadow. Use INSERT, UPDATE and DELETE on 
that table and have triggers that duplicate those actions into 
pg_shadow. The triggers need to be configured in slony as well so that 
replicating the table will have the same effect through triggers on the 
subscribers.

Keep in mind that this whole thing will only work if the entire instance 
is for one single database. pg_shadow is a shared system catalog. 
Another reason why it isn't really good to have a user per application user.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #