Re: Further patch for VS2005

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

In response to

Browse pgsql-patches by date

  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