Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> Somebody had better double-check that. We don't need to be
>>> "pessimistic", we need to be *correct*, because the align values had
>>> better match the way the compiler will lay out a C struct. Otherwise
>>> struct-based access to catalog rows will fail. (I'm not sure if there
>>> are any system catalogs with float8 or int64 columns, but I'd sure not
>>> want to find out that we couldn't have one because of misconfiguration
>>> of MSVC builds.)
>
>> How do I double-check this?
>
> The configure script checks it by declaring
>
> struct {
> char pad;
> TYPE field;
> } foo
>
> and then measuring offsetof(foo, field), for each interesting TYPE.
Ok. Confirmed that they are all the same.
>>> I see though that the comment in pg_config.h.win32 claims it was derived
>>> from mechanically-generated configure output, so unless that's lying
>>> it should be OK already.
>
>> It's not - it started out as a copy of the output of ./configure on mingw.
>
> "Started out as"? Good luck keeping it in sync, if it's not
> mechanically created.
It's been working fine for a year... In general, any new features need
to be added to the build system anyway, which gets done when the feature
is checked to be working on the msvc build (see the gssapi or the xml
stuff for example). Since we don't have ./configure there.
There's no point in automatically adding the "#undef" rows if there is
no system that changes them into #defines if they're used..
//Magnus
