-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > To emulate this logic in a PostgreSQL trigger, I think I can define > a security definer trigger function created by the database > superuser with session_replication_mode set for the function to > 'replica'. It's a lie, but it seems like it does the right thing -- > triggers won't be called for what this trigger does unless we flag > them as ENABLE ALWAYS or ENABLE REPLICA. We will want to do this > for our triggered change notifications and replication publishing > triggers. > > I assume this will prevent us from using, for example, Slony with > such a database, but are there any other down sides of abusing this > GUC in this fashion? Does anyone see a reasonable alternative? I don't see any downsides. And technically you can use the old version of Slony, or a quick hack to Bucardo to force it to use the old system catalog hack method (which I've actually done with a client before - don't ask why). An alternative would be to have a quick check at the top of the trigger checking for a certain state to be set before proceeding (e.g. custom GUC or just a weird entry on an existing one, like ssl_renogiation_limit = 543210). - -- Greg Sabino Mullane greg@xxxxxxxxxxxx End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201106211944 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk4BLaEACgkQvJuQZxSWSsiXSwCfQt+U5vMzyiRsMsQ9OF9Myleg 6/EAoNuqd4SI0Ttj4L9rS1FfXx7o1elQ =XS1r -----END PGP SIGNATURE----- -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
