From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk> |
Subject: | Re: Compiling libpq with VC6 |
Date: | 2004-08-18 19:31:53 |
Message-ID: | 4123AEA9.4050005@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-08-18 19:35:30 | Re: Compiling libpq with VC6 |
Previous Message | Bruce Momjian | 2004-08-18 18:35:20 | Re: 8.0 libpq: missing get_home_path() |