Andreas Pflug <pgadmin at pse-consulting.de> writes:

> Christopher Browne wrote:
>>>Correct. So either subscribing an empty set must be disabled, or that
>>>problem caught in slon. Seems I'll have to modify the event queue
>>>manually.
>> It's a bit harder than that...  One could use SET MOVE TABLE or SET
>> DROP TABLE to empty out a set.
>> But certainly adding an advisory notice that subscribing an empty set
>> is a bad idea would be a reasonable thing to do.
>> FYI, the problem is where there are no tables.  Having sequences
>> doesn't help :-(.
>
> Why is it a problem to catch the no-table-in-subscription case in slon
> and skip that offending cursor, or refuse to subscribe such a set?

It isn't a problem; there is a NOTICE being raised as things stand now.

See slony1_funcs.sql in CVS HEAD:

        -- --- 
        -- Check to see if the set contains any tables - gripe if not - bug #1226 
        -- --- 
        if not exists (select true     
                from @NAMESPACE at .sl_table 
                where tab_set = p_sub_set) then 
                raise notice ''subscribeSet:: set % has no tables - risk of problems - see bu\
g 1226'', p_sub_set; 
                raise notice ''http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?\
1226''; 
        end if; 
 
It's just that "completeness sake" dictates mentioning that this isn't
the only scenario where a set can have no tables.  I can't call the
problem "solved" unless all of the scenarios are addressed.
-- 
let name="cbbrowne" and tld="ca.afilias.info" in name ^ "@" ^ tld;;
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)