Horton

Re: windows consolidated cleanup

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-04-24T16:25:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move include for Python.h above postgres.h to eliminate compiler warning.

Andrew Dunstan <andrew@dunslane.net> writes:
> The attached patch is intended to clean up a bunch of compiler warnings 
> seen on Windows due to mismatches of signedness or constness, unused 
> variables, redefined macros and a missing prototype.

BTW, this hunk:

> *** a/src/pl/plpython/plpython.c
> --- b/src/pl/plpython/plpython.c
> ***************
> *** 84,89 **** typedef int Py_ssize_t;
> --- 84,101 ----
>   		PyObject_HEAD_INIT(type) size,
>   #endif
  
> + /*
> +  * Some Python headers define these two symbols (e.g. on Windows) which is
> +  * possibly a bit unfriendly. Use the Postgres definitions (or lack thereof).
> +  */ 
> + #ifdef HAVE_STRERROR
> + #undef HAVE_STRERROR
> + #endif
> + 
> + #ifdef HAVE_TZNAME
> + #undef HAVE_TZNAME
> + #endif
> + 
>   #include "postgres.h"
  
>   /* system stuff */

is indicative of far worse problems than the one it claims to solve.
This file is in fundamental violation of the first commandment of
Postgres #includes, which is "thou shalt have no other gods before c.h".
We need to put postgres.h *before* the Python.h include.  I don't know
what issues led to the current arrangement but it is fraught with
portability gotchas.  In particular it's just about guaranteed to fail
on platforms where <stdio.h> reacts to _FILE_OFFSET_BITS --- plpython.c
is going to get compiled expecting a different stdio library than the
rest of the backend.

			regards, tom lane