"Don Walker" <[EMAIL PROTECTED]> writes: > Since my state is fairly complex I intend to make my state value type text > to give myself a block of memory in which I can manage the various pointers > I need. I realize that I will need to be careful about alignment issues and > intend to store the state as a large struct in the data area of the text.
> Q1 Is this approach for the state variable reasonable? Not very. In the first place, it's a horrid idea to put non-textual data into a text datum. This is not invisible-to-the-user stuff, they can easily see it by calling your transition function directly. bytea might be a better choice for holding random data. In the second place, your reference to pointers scares me. You cannot assume that the nodeAgg code won't copy the transition value from one place to another, so internal pointers aren't going to work. Can you use offsets instead? > The existing C code that I've inherited makes heavy use of static and global > variables. I immediately assumed that for thread safety I'd need to roll any > of these variables that need to survive a function call into the state > variable struct and change any that were just for convenience instead of > parameters into parameters to my internal functions. There are no threads in the backend. What you *do* need to worry about is parallel evaluation of multiple instances of your aggregate, for instance "select myagg(x), myagg(y) from table". Another tricky problem is reinitialization if a query fails partway through and so you never get as far as running your finalization function. It's certainly easiest if you can keep all your state in the transition datum. People have been known to cheat, though. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org