From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Further patch for VS2005 |
Date: | 2006-06-26 21:01:34 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA0FAA1@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
> > *** src/pl/plpython/plpython.c 25 Jun 2006 00:18:24
> -0000 1.83
> > --- src/pl/plpython/plpython.c 26 Jun 2006 13:58:56 -0000
> > ***************
> > *** 10,16 ****
> > --- 10,19 ----
> > /* Python uses #pragma to bring in a non-default
> libpython on VC++ if
> > * _DEBUG is defined */
> > #undef _DEBUG
> > + /* Also hide away errcode, since we load Python.h before
> postgres.h
> > + */ #define errcode __vc_errcode
> > #include <Python.h>
> > + #undef errcode
> > #define _DEBUG
> > #else
> > #include <Python.h>
>
> BTW, it strikes me as a fairly bad idea to be including
> <Python.h> first; that goes directly against the conventions
> we established to be sure that largefile support doesn't
> break. Has anyone looked into making plpython.c conform to
> project standards by including postgres.h first?
Not me. Last time I did something like that it came back and bit me
because apparantly python does things significantly different on
different platforms. Now that we have the buildfarm it might be worth a
try. I don't have a *nix box around with python ATM, but if nobody beats
me to it I can try it later...
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-06-26 21:26:03 | Re: [HACKERS] Overhead for stats_command_string et al, take 2 |
Previous Message | Alvaro Herrera | 2006-06-26 20:54:07 | Re: [PATCHES] Non-transactional pg_class, try 2 |