-----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@turnstep.com
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-----