On Mon, Feb 3, 2014 at 11:36 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@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
elog_for_datestyle.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
