Wed Mar 5 14:15:55 PST 2014
- Previous message: [Slony1-bugs] [Bug 332] Exclude unreplicable objects from replication
- Next message: [Slony1-bugs] [Bug 332] Exclude unreplicable objects from replication
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
http://www.slony.info/bugzilla/show_bug.cgi?id=332 Christopher Browne <cbbrowne at ca.afilias.info> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from Christopher Browne <cbbrowne at ca.afilias.info> 2014-03-05 14:15:55 PST --- Here is a preliminary proposal for implementation. https://github.com/cbbrowne/slony1-engine/commit/f988bc8db10b37160949b7ea5978317068fd5806 I am proposing here to do a somewhat fuzzy matching of which tables are to be refused; I treat that if the namespace starts with "_" and the table name starts with "sl_", then the table is to be treated as a replication table. if v_tab_nspname ~ '^_.*' and v_tab_relname ~ '^sl_.*' then raise exception 'Slony-I: setAddTable_int(): % appears to be a replication configuration table and cannot be replicated', p_fqname; end if; That may be a bit too open-ended. What I don't want to do is to be insufficiently open-ended; it would be broken for one slony installation to break another one. It would be a more precise test to check that the namespace in question has one or more well-known Slony tables within it. (e.g. - I could check that, in addition, there's the table sl_log_1 in the same namespace). Does that approach seem agreeable? -- Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
- Previous message: [Slony1-bugs] [Bug 332] Exclude unreplicable objects from replication
- Next message: [Slony1-bugs] [Bug 332] Exclude unreplicable objects from replication
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-bugs mailing list