Peter Eisentraut <pe...@eisentraut.org> writes:
> On 09.08.23 08:42, Laetitia Avrot wrote:
>> My question is very simple: Do you oppose having this feature in Postgres?
> I think this is pretty harmless(*) and can be useful, so it seems
> reasonable to pursue.
I actually do object to this, because I think the concept of "server
name" is extremely ill-defined and if we try to support it, we will
forever be chasing requests for alternative behaviors. Just to start
with, is a prospective user expecting a fully-qualified domain name
or just the base name? If the machine has several names (perhaps
associated with different IP addresses), what do you do about that?
I wouldn't be too surprised if users would expect to get the name
associated with the IP address that the current connection came
through. Or at least they might tell you they want that, until
they discover they're getting "localhost.localdomain" on loopback
connections and come right back to bitch about that.
Windows likely adds a whole 'nother set of issues to "what's the
machine name", but I don't know enough about it to say what.
I think the upthread suggestion to use cluster_name is going to
be a superior solution for most people, not least because they
can use it today and it will work the same regardless of platform.
> (*) But we should think about access control for this. If you're in a
> DBaaS environment, providers might not like that you can read out their
> internal host names.
There's that, too.
regards, tom lane
