On 12/18/06, Jan Wieck <[EMAIL PROTECTED]> wrote:
The problem is that from the moment there are more columns than the trigger knows about, update and delete statements let the trigger access the attkind (that funny 'kvvvvvv' string) info past its end. Meaning, the check if to include that column into the WHERE clause of the replication update/delete is done against random bytes on the stack. If one of them happens to be a 'k', the trigger will attempt to add it and its value to the where clause and if that value happens to be a NULL your transaction will go kaput.
do i understand correctly, that this insecure way of adding columns would actually work as long as i dont add "key" column? please do understand my question - i know it is not appropriate way of doing things. i know it is not supported. but i just would like to know real limits. Andrew is right, I actually didn't add that check. But this whole
discussion makes me think about adding it again ...
but why? this single thing is actually a great point - you can *technically* add a column without any interruptions, just do it in correct order, with neccessary steps, and it *should* work. nobody gives any guarantees, but hey - that's how the software is built - nobody gives any guarantees ;-) best regards, and really BIG thanks for good work on slony, depesz -- http://www.depesz.com/ - nowy, lepszy depesz
_______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
