On Mon, Feb 3, 2014 at 11:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
>> Also as per below link, it seems that PGDLLIMPORT is required for
>> exported global variables.
>> http://msdn.microsoft.com/en-us/library/8fskxacy(v=vs.80).aspx
>
> That was what we'd always assumed, but the fact that postgres_fdw has been
> working for the last year (on everything except narwhal) puts the lie to
> that as a blanket assumption.
>
> So what I want to know now is how come it wasn't failing; because then
> we might be able to exploit that to eliminate the need for the PGDLLIMPORT
> cruft everywhere.
Today, I had tried to debug the same scenario on Win XP 32-bit, but the value
for DateStyle is junk on that m/c as well. Is it possible that someway we can
check on buildfarm m/c (Windows) where regression test is passing what is
the value of DateStyle.
We can use something like attached patch to print the value in log.
In my test, it prints the values as below:
Without using PGDLLIMPORT for DateStyle
LOG: Value of DateStyle is: 326903295
Using PGDLLIMPORT for DateStyle
LOG: Value of DateStyle is: 1
In the function where it is used, it seems to me that it is setting DateStyle
as ISO if it is not ISO and function configure_remote_session() will set it
to ISO initially. So basically even if the value of DateStyle is junk, it will
just do what we wanted i.e setting it to ISO. Does the failure is due to reason
that it is not expecting DateStyle to be ISO and due to junk value of this
parameter it sets the same to ISO.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com