Currently, the Postgres.app GUI can only manage servers using the binaries in the application bundle.

However, it would be nice if we could use the same GUI for starting/stopping servers with other binaries:

• start/stop Homebrew servers
• start/stop legacy servers that are no longer included with Postgres.app
• start/stop a locally compiled version of PostgreSQL (useful for hacking on PostgreSQL itself)

There is a pull request that implements this: PR 797: Add custom postgres installation support

However, there are some issues we need to discuss before merging that pull request. I am collecting these issues here for discussion. The following issues were raised by @robertjpayne, @tbussmann, @anthonydb and myself:

• PostgreSQL requires a LC_ALL environment variable if it's been compiled with --enable-nls.
• Postgres.app always runs PostgreSQL using the current user. I think this matches Homebrew, but EnterpriseDB uses a separate user account. So if people try to use Postgres.app to control the EnterpriseDB server, that might lead to unexpected results.
• What about the auth_permission_dialog extension? external binaries are unlikely to have this installed. Disabling it for custom binaries only would make the generic switch in the preferences a bit confusing.
• What commands to use to start, stop and especially initialise a 'foreign' cluster? I'm not sure the existing defaults of Postgres.app work well for people who have a need for an advanced feature like the one we're designing here.
• How do I deal with externally started servers? There is a good chance that they are not running on the port configured within Postgres.App. Postgres.App passes the port configured in the UI when the server is started, while others are likely to modify the postgresql.conf file.
• There is no guarantee that we will be able to connect to an external server, as we don't know the users and authentication configured. Fortunately, we have already implemented some heuristics and a graceful state if the connection is not possible.
• How do we deal with updates to the 'foreign' binaries?
• We need to make sure that this does not conflict with the logic we have to deal with servers configured with binaries of Postgres.App in different locations / copies and running multiple instances of the app.
• Support for custom binaries adds complexity to planned features such as automatic extension updates, major version upgrades, externally loadable Python and extensions, backup and restore.
• We should try to keep the current setup experience as streamlined as it is.

I don't think any of these are deal breakers, but we need to make sure to discuss them before merging the pull request. I think the last part is especially important: adding the custom PostgreSQL installation support should not make Postgres.app any harder to use for people who do not use the feature.