Aha -- that's the answer.

select tgname,count(*) from  pg_trigger group by 1 having count(*) > 1 ;
          tgname         | count
------------------------+-------
price_ins              |     3
price_before_del       |     3
price_before_ins_upd   |     3
price_upd              |     3
run_market_aft_ins_upd |     3
updates_after_ins      |     2
(6 rows)

On Jun 29, 2006, at 2:13 PM, Christopher Browne wrote:

> 2.  The question becomes:  How did an extra trigger get into place?


We're using other schemas on our staging and testing servers. Our  
database has a price table and an updates table in its public schema,  
which are both slonied to the slave nodes. The public.price table has  
triggers to track changes on this table and write the changes to the  
public.updates table.

When we want to test things in our database, on the staging and  
testing servers, we create an independent price table + updates table  
in another schema and test our stuff there using the same trigger  
mechanism, but on test data -- so the triggers have the same names,  
but are attached to a table in a different schema.

I guess the work around here would be to drop the triggers with the  
same names in the other schemas before applying DDL changes. STORE  
TRIGGER doesn't work here, because the trigger isn't on the table  
being slonied --

Is there a way that slony can recognize that that there can be two  
triggers with the same name, one on a slonied table, one on a non- 
slonied table, in different schemas? I realize this is an edge case,  
but it gives us mightly useful functionality that I'm loath to lose.




######################################################################
This e-mail is confidential and should not be redistributed or
forwarded by the recipient.  The information contained in this e-mail
message is intended only for the use of the individual or entity named
above.  If the reader of this message is not the intended recipient or
you have received this communication in error, please immediately
notify us by telephone.  Receipt by anyone other than the intended
recipient is not a waiver of any work-product or, if applicable,
attorney-client privilege.

This e-mail does not constitute an offering of any security.  Such an
offering may only be made by means of a private placement memorandum
or other disclosure document.  Nothing in this e-mail constitutes
investment advice.  Past performance is not indicative of future
results.  All e-mail to and from Millburn Ridgefield Corporation and
its affiliates is monitored, stored and made available to regulators
if requested.
######################################################################