| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, 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 17:17:19 |
| Message-ID: | 2137.1092849439@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2004-08-18 17:17:44 | Re: 8.0 libpq: missing get_home_path() |
| Previous Message | Bruce Momjian | 2004-08-18 17:08:35 | Re: 8.0 libpq: missing get_home_path() |