From: | Dinesh Kumar <dinesh(dot)kumar(at)enterprisedb(dot)com> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch for EDB binary path not set by default. |
Date: | 2013-10-14 09:13:00 |
Message-ID: | CAKWsr7jb_CGs8Syu2xzaxMPHQe9XeWpgOe_KcS4EKytLhcRV2A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
Hi Dave,
Thanks for your valuable inputs.
On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> Hi
>
>
> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar <
> dinesh(dot)kumar(at)enterprisedb(dot)com> wrote:
>
>> Hi Dave/Team,
>>
>> When we install a 32-bit pgAdmin-III in a windows 64-bit machine, which
>> is already having the 64-bit EnterpriseDB database installed, then EDB
>> binary path not set to by default.
>>
>> Further to my observation, below is the mechanism how the pgAdmin looks
>> for the PPAS binary path.
>>
>> A) Read the settings.ini for the entry "EnterpriseDBPath" and get the
>> value.
>>
>> B) Read the "EnterpriseDBPath" as a key in the registries. If the key is
>> not found, then create one key and assign the value of settings.ini file.
>>
>> C) If the registry is found, and still the value of "EnterpriseDBPath" is
>> null, then we are checking the %PATH% which will be having the
>> "pg_dump.exe" file and it's a type of "EnterpriseDB".
>>
>> D) If we don't find any "pg_dump.exe" edb version, then we go for the
>> default locations to search for the edb version.
>>
>> I have verified the above A, B and C cases, and those are working fine in
>> a 64-bit machine. But the case D is not working as expected in a 64-bit
>> machine. Hence, would like to submit a patch for this case.
>>
>> Kindly let me know your inputs on this patch.
>>
>
> I don't think you can do it that way - what if the directory name doesn't
> end in "(x86)"? You can configure Windows to use any arbitrary directory
> for the Program Files folders. I suspect you'll need to use a preprocessor
> macro to handle the 32 vs. 64 bit cases accordingly.
>
Sorry for the delay on this issue.
I have done some google around the same problem, and found the solution to
use "programw6432" environment variable , if a 32 bit application runs in a
64 bit machine. But, this option only works on windows 7 and windows 2008
R2 onwards. And after spending some time, i have found one suitable
solution for this case, which we need to read the key "ProgramFilesDir"
from the registry "HKEY_LOCAL_MACHINE\\
SOFTWARE\\Microsoft\\Windows\\CurrentVersion", and i have implemented
this mechanism
using pgRegKey.
Here i have used, "wxIsPlatform64Bit()" as an alternative to preprocessor
macros.
Kindly let me know your inputs on this patch.
Thanks in advance.
Regards,
Dinesh
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
Attachment | Content-Type | Size |
---|---|---|
Fix_EnterpriseDBPath_Notset_Bydefault-V2.patch | application/octet-stream | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Neel Patel | 2013-10-14 12:51:45 | Regarding storenode in Slony |
Previous Message | Linreg | 2013-10-14 08:24:59 | pgAgent: C++ Port - Patch Review |