Re: Adding a pg_servername() function

From: Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>
To: GF <phabriz(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Laetitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Adding a pg_servername() function
Date: 2023-08-09 20:05:21
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

## GF (phabriz(at)gmail(dot)com):

> In the past I needed such a pg_servername() function because in a project I
> was engaged on they needed to distribute "requests" directed to a in-house
> management service running on network servers, and each one had a DB, so we
> went with pglogical to be used as a (transactional) messaging middleware.

That sounds like an "if all you have is a hammer" kind of architecture.
Or "solutioning by fandom". Short of using an actual addressable
message bus, you could set up the node name as a configuration
parameter, or use cluster_name, or if you really must do some
COPY FROM PROGRAM magic (there's your access control) and just store
the value somewhere.
The more examples of use cases I see, the more I think that actually
beneficial use cases are really rare.

And now that I checked it: I do have systems with gethostname()
returning an FQDN, and other systems return the (short) hostname
only. And it gets worse when you're talking "container" and
"automatic image deployment". So I believe it's a good thing when
a database does not expose too much of the OS below it...


Spare Space

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2023-08-09 21:45:27 Re: PG 16 draft release notes ready
Previous Message Melanie Plageman 2023-08-09 18:52:33 Re: Show WAL write and fsync stats in pg_stat_io