Thread: pg_pwd trigger to be removed

Because of the problems that were pointed out, I'm inclined to remove the
pg_pwd updating trigger again. I can offer you the non-initdb requiring
variant (just remove the trigger definition in initdb) or the
clean-sweeping one (remove the trigger function from the backend). Okay,
the first one will require some sort of intervention as well, eventually,
but you see the difference.

My new take on the situation is actually that there shouldn't be a reason
to tinker with the systems catalogs period. In the case of pg_shadow
that's not entirely possible (catupd and trace can't be adjusted
otherwise), but that can be fixed (not now). After all they're called
*system* catalogs. If someone thinks they can rename a table by updating
pg_class.relname -- good night!

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Because of the problems that were pointed out, I'm inclined to remove the
> pg_pwd updating trigger again. I can offer you the non-initdb requiring
> variant (just remove the trigger definition in initdb) or the
> clean-sweeping one (remove the trigger function from the backend). Okay,
> the first one will require some sort of intervention as well, eventually,
> but you see the difference.

I think we liked the trigger, but wanted it to activate only on
transaction commit.  I think Tom Lane had some ideas on this.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Peter Eisentraut <peter_e@gmx.net> writes:
> Because of the problems that were pointed out, I'm inclined to remove the
> pg_pwd updating trigger again.

Actually, what I'd like to see is a fix that makes the trigger robust.
Maybe that's too much work for 7.0.

If we had a robust solution for this problem, then we could apply the
same method to export a flat-file equivalent of pg_database, which could
be read during backend startup.  That would allow us to get rid of some
incredibly grotty (and not 100% reliable) code that tries to read
pg_database before the transaction management code has been fired up :-(

> My new take on the situation is actually that there shouldn't be a reason
> to tinker with the systems catalogs period.

Maybe so, but we still could make good use of an end-of-transaction
trigger to update pg_pwd from pg_shadow.  Right now, rollback of a
pg_shadow update doesn't really work right even if you did it via
CREATE/ALTER USER.
        regards, tom lane