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 |
Message-ID: | ZNPxgXr6QocGIHzc@elch.exwg.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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...
Regards,
Christoph
--
Spare Space
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 |