> For my customer, their use case is to be able from an SQL client to double > check they're on the right host before doing things that could become a > production disaster.
Why not use cluster_name for that? Even if it may not be relevant for their setup, there might be multiple clusters on the same host (multiple clusters with the same hostname) or you database could be hiding behind some failover/loadbalancer mechanism (multiple hostnames in one cluster), thus using the hostname to identify the cluster is totally not universal (the same goes for the monitoring/metrics stuff). And there's of course inet_server_addr(), if you really need to double-check if you're connected to the right machine.
Hello Christoph,
I understand your point and sure enough, my customer could set and use the cluster_name for that purpose. I totally disagree with using inet_server_addr() for that purpose as there are so many different network settings with VIPs and so on that it won't help. Also, a socket connection will give a NULL value, not that it's *that* bad because if it's a socket, you're running locally and could still use `\! ifconfig`, but it does not work on some configurations (docker for example). Also, most humans will find it easier to memorize a name than a number and that's one of the reasons why we remember websites' URLs instead of their IP.
I still disagree with the monitoring part. A good monitoring tool will have to reconcile data from the OS with data from the Postgres cluster. So that, we kind of need a way for the monitoring tool to know on which host this particular cluster is running and I think it's smarter to get this information from the Postgres cluster.
Of course, I do love the idea that Postgres is agnostic from where it's running, but I don't think this new function removes that.