Re: [PATCHES] Compiling libpq with VC6
Bruce Momjian wrote: The problem with this approach is that it has us using the non-reliable libc rename/unlink rather than our own in libpq. Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Compiling libpq with VC6
Andreas Pflug wrote: Bruce Momjian wrote: The problem with this approach is that it has us using the non-reliable libc rename/unlink rather than our own in libpq. Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. I would like to keep full Unix semantics for these functions even in libpq, if possible. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Compiling libpq with VC6
Bruce Momjian [EMAIL PROTECTED] writes: Andreas Pflug wrote: Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. I would like to keep full Unix semantics for these functions even in libpq, if possible. libpq doesn't use either rename or unlink AFAIK. However, if we make the patch be something involving #ifdef FRONTEND, then it will affect other code that might want to use those. One thing that hasn't been real clear to me is why this only affects fe-lobj.c, when we have many other files that include io.h after including postgres.h. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Compiling libpq with VC6
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Andreas Pflug wrote: Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. I would like to keep full Unix semantics for these functions even in libpq, if possible. libpq doesn't use either rename or unlink AFAIK. However, if we make the patch be something involving #ifdef FRONTEND, then it will affect other code that might want to use those. One thing that hasn't been real clear to me is why this only affects fe-lobj.c, when we have many other files that include io.h after including postgres.h. Quite simple: mingw includes do *not* conflict. Only a minority of tools is object to VC6 compilation, ultimately only libpq is needed. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Compiling libpq with VC6
Andreas Pflug wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Andreas Pflug wrote: Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. I would like to keep full Unix semantics for these functions even in libpq, if possible. libpq doesn't use either rename or unlink AFAIK. However, if we make the patch be something involving #ifdef FRONTEND, then it will affect other code that might want to use those. One thing that hasn't been real clear to me is why this only affects fe-lobj.c, when we have many other files that include io.h after including postgres.h. Quite simple: mingw includes do *not* conflict. Only a minority of tools is object to VC6 compilation, ultimately only libpq is needed. True, only MSVC conflicted. Maybe no one has compiled anything but libpq using MSVC, particularly psql. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Compiling libpq with VC6
Tom Lane wrote: Hm. Given that we now support a native Windows port, do we care about building libpq with VC6 anymore? Yes please! I just tried: I renamed libpq.a to libpq.lib. pgAdmin links with that, but will crash. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Compiling libpq with VC6
Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: One thing that hasn't been real clear to me is why this only affects fe-lobj.c, when we have many other files that include io.h after including postgres.h. Quite simple: mingw includes do *not* conflict. Only a minority of tools is object to VC6 compilation, ultimately only libpq is needed. Hm. Given that we now support a native Windows port, do we care about building libpq with VC6 anymore? Why wouldn't you just use the library as built with mingw? If we were moving in the direction of making the whole project buildable with VC6, that would be one thing; but as far as I know that is explicitly not part of the plan. So why should we continue to support a partially-baked port when we have a full port? VC seems broken only in the very minor way of io.h. I don't know of any other issues. Doesn't seem like enough of a reason to abandon the build environment. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Compiling libpq with VC6
The problem with this approach is that it has us using the non-reliable libc rename/unlink rather than our own in libpq. I have already applied a fix that allows the code to compile cleanly. --- Andreas Pflug wrote: libpq currently doesn't compile with vc6. The reason is a conflict of prototypes for rename and unlink, which happens when fe-lobj.c includes io.h. The attached patch will redefine unlink and rename only if FRONTEND is not defined. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
