On 12/18/06, Jan Wieck <JanWieck at yahoo.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20061219/ec63cbaa/attachment-0001.html