Magnus Hagander <magnus@hagander.net> writes: > I think this can be considered a "new feature" and not just a plain bugfix, > so it should probably only go into HEAD. I am very nearly ready to demand that ecpg as a whole be reverted to its state as of Saturday, with all the patches since then held for 8.4 development. At no point since Sunday morning has ecpg been passing buildfarm testing, and I see no activity indicating that it's about to get fixed. You guys are holding up beta release with work that by any legitimate definition is new-feature development, and shouldn't be under consideration at all at this point. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

Michael Meskes <meskes@postgresql.org> writes: > Sorry, my bad. Seems I got this mixed up. Once we enabled testing for > ecpg we had some problems to be sorted out, but right now only the > DllMain thing seems to be a problem. > Since I do not know whether we really need DllMain could anyone please > test whether ecpg builds correctly without it? It looks to me like we should not need it, if we instead add code to initialize the mutexes properly on Windows (a la the way it's done in libpq). I can prepare a patch, but I don't have the ability to test it on Windows --- will anyone be around who can, in an hour or so? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

I wrote: > Michael Meskes <meskes@postgresql.org> writes: >> Since I do not know whether we really need DllMain could anyone please >> test whether ecpg builds correctly without it? > It looks to me like we should not need it, if we instead add code to > initialize the mutexes properly on Windows (a la the way it's done > in libpq). Hm, I take that back --- the other reason it's there is as a kluge to avoid supporting pthread_once(). This code all looks pretty darn hokey, not to mention that it ought to be merged with libpq's pthread-win32.c, but fixing it seems not a one-hour proposition. >> AFAIRC (and hopefully I'm right this time) >> multithreading never worked under msvc so we might have to set >> thread-safety to disabled on these systems for ecpg for the time being. If it didn't work then this seems clearly new-feature-development. I think Magnus' idea of providing an exports list would be worth trying, if someone can try it promptly; failing that, we need to revert this patch. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Magnus Hagander <magnus@hagander.net> writes: > Michael Meskes wrote: >> So, does an explicit export list help? If so I'm all for it. There is no >> need to export all symbols. I always tried to keep the number of symbols >> that get exported but are not needed low. So this will give the best >> result possible. > Yeah, it does seem to fix it. That's very good news. If Michael can put together an export list soon then we'll be in good shape. Michael: you should bump the major version number of ecpglib when you do this. Removing the not-officially-exported visible symbols *is* an ABI break. You may think there isn't anything depending on them, but remember how we thought that (twice) for libpq too. Bumping the major version number will be cheap insurance against complaints later. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly