The following very quick patch (against 1.2.12) provides the following changes: - when scanning attributes looking for key columns (in UPDATEs and DELETEs), stop when we reach the end of the attkind string - when creating the triggers, final "v"s are stripped Result: - one can add columns (without defaults, constraints, etc.) to tables (destinations first, origin last) without changing the logtrigger and without using EXECUTE SCRIPT - as a bonus we save a few cycles in updates and deletes --- src/backend/slony1_funcs.c.orig Wed Nov 21 15:43:24 2007 +++ src/backend/slony1_funcs.c Wed Nov 21 15:45:13 2007 @@ -821,6 +821,8 @@ continue; attkind_idx++; + if (!attkind[attkind_idx]) + break; if (attkind[attkind_idx] != 'k') continue; col_ident = (char *)slon_quote_identifier(SPI_fname(tupdesc, i + 1)); @@ -888,6 +890,8 @@ continue; attkind_idx++; + if (!attkind[attkind_idx]) + break; if (attkind[attkind_idx] != 'k') continue; col_ident = (char *)slon_quote_identifier(SPI_fname(tupdesc, i + 1)); --- src/backend/slony1_funcs.sql.orig Wed Nov 21 15:45:35 2007 +++ src/backend/slony1_funcs.sql Wed Nov 21 15:53:11 2007 @@ -5029,6 +5029,11 @@ end loop; -- + -- Strip final 'v's as these are not needed by the logtrigger + -- + v_attkind := regexp_replace(v_attkind,''v*$'',''''); + + -- -- Return the resulting attkind -- return v_attkind; -- Jacques Caron <jc@oxado.com>
I had been putting this off, as it seemed as though it might be undesirable to make a change that might be interpreted as commending use of mechanisms other than EXECUTE SCRIPT to manage changes to tables. In retrospect, the other changes in v2.0 make that counter-issue go away. EXECUTE SCRIPT doesn't run the functions that continually alter this "Morse code" anymore.
Created attachment 20 [details] Fix for bug #18
I have attached a patch against CVS HEAD that seems to handle how the code is now... Note that I have added an example of a table that exercises this logic to test1. Jacques, could you review this versus HEAD to verify that the changes to src/backend/slony1_funcs.c are already in the code? Thanks!
This is the current behavior in REL_2_0_STABLE as well as HEAD. Closing this bug as fixed.