That error message indicates that the PostgreSQL clientpsql is correctly installed on your machine, but you seem to have no PostgreSQL server running, or if there is one it is not listening on the default socket.
Let’s take a step back: what were you trying to accomplish?
I appreciate it may not have anything to do with the daml install but the $PATH file looked strange to me with all the instances of ‘Users/sonjaparsell/.daml/bin’ and I don’t really understand what that means…
I’m trying to start psql for a different project and my debugging for that led me to the PATH file, which when I saw all the daml paths, I thought there might have been an issue that is causing psql not to run a server. I’ll keep on debugging – thanks for taking a look!
So the PATH environment variable, which you can print with echo $PATH, is a text string that represents a list of folders. Each entry in the list should start with a / and be an absolute (i.e. “from the root”) path to a folder. Entries are separated by :.
It’s pretty common to have various “hooks” that “add” to the PATH and that can be run multiple times in some circumstances. From that perspective, having the same entry multiple times in your PATH is not an issue.
The way PATH works is that, every time you type anything in your shell, your computer is going to look inside each of the listed folders, one by one, in order, to find an executable that matches the first word in your shell command. That process stops as soon as it finds a match.
From that perspective, it’s easy to see that duplicate entries are not an issue (except maybe for performance reasons, but this should all be so fast it doesn’t matter), but that order of entries may matter. If you have an executable with the same name in multiple folders, the process will find (and run) the first one.
The daml/bin folder should not contain anything that conflicts with PostgreSQL binaries, as far as I’m aware, so that’s unlikely to be the issue, but if you do find a conflict please let us know.
If you know the server exists, and have otherwise been able to verify it is running, then the issue is likely to be that you’re not giving the server address to your psql invocation. By default, it tries to connect through a local file socket, but, depending on where your PostgreSQL server is running, you may need to give it an explicit network address instead.
I may be able to help you more with more information about what you’re doing, but at this point that’s all I have.