Sync logic for auth_permission_dialog.dialog_executable_path with binary path logic

[tbussmann]

Currently, auth_permission_dialog.dialog_executable_path seems to be always taken from the application bundle, which has started the server. However the binaries to do so are preferably taken from the plist if these exist and differ from the own application path. This can lead to a situation where the server is running, but the permission helper cannot be found anymore:

• have Postgres.app in /Applications
• configure a server, init and stop it
• run Postgres.app from a dmg
• start the server
• verify the binary path in server settings: not in translocation
• SHOW auth_permission_dialog.dialog_executable_path;: path in translocation
• quit the app from dmg - the server is not stopped because it is not running the App's binaries
• start App again from dmg
• no connection possible as we are now running from a different translocation location and the permission dialog helper can no longer be found at the old path. In log FATAL: auth_permission_dialog.dialog_executable_path is not a file

[jakob]

My thinking was that I consider the PostgresPermissionDialog executable part of the GUI, which is why the app passes the path to its own helper executable rather than look for the executable relative to the bin path.

There are two reasons why I thought that the status quo was a reasonable choice:

1. The binary directory might not be from a Postgres.app. It could theoretically be installed from source, from homebrew, etc. However, in that case the auth_permission_dialog extension would most likely not be included, so it wouldn't be possible to use it anyway.

2. Currently the PostgresPermissionDialog checks the path of PostgreSQL clients and automatically allows all binaries from the same application bundle to connect. Otherwise you'll get a permission prompt for the GUI app.

However, all those are border cases, so I'm not totally against your suggestion.

Another approach to fix this particular issue might be to change the logic so that a translocated GUI quits all PostgreSQL servers it started rather than just look at the bin path?