Hi all,
FWIW, I too believe this is a feature that has been sorely missing for
years, leading us to use awful hacks like running "hostname" as PROGRAM and
retrieving its output.
Ideally that's what this function (or GUC) should return, what the system
believes its hostname to be. It doesn't even h
Dear Christoph,
Please find my answers below.
Le mer. 9 août 2023 à 22:05, Christoph Moench-Tegeder
a écrit :
> ## GF (phab...@gmail.com):
>
> And now that I checked it: I do have systems with gethostname()
> returning an FQDN, and other systems return the (short) hostname
> only.
The return
Dear Tom,
Thank you for your interest in that patch and for taking the time to point
out several things that need to be better. Please find below my answers.
Le mer. 9 août 2023 à 16:04, Tom Lane a écrit :
> I actually do object to this, because I think the concept of "server
> name" is extreme
Le mer. 9 août 2023 à 17:32, GF a écrit :
>
> Would it be less problematic if the function were called pg_gethostname()?
> @Laetitia: why did you propose that name? maybe to avoid clashes with some
> extension out there?
>
>
I used that name to be kind of coherent with the inet_server_addr(), but
## GF (phab...@gmail.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
GF writes:
> On Wed, 9 Aug 2023 at 16:05, Tom Lane wrote:
>> I actually do object to this, because I think the concept of "server
>> name" is extremely ill-defined
> But the gethostname() function is well defined, both in Linux and in
> Windows.
Sure, its call convention is standardized. But I
On Wed, 9 Aug 2023 at 16:05, Tom Lane wrote:
> Peter Eisentraut 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.
Peter Eisentraut 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
Hi everybody,
On 09.08.23 08:42, Laetitia Avrot wrote:
> I agree that the feature I'm suggesting could be done with a few tricks.
> I meant to simplify the life of the user by providing a simple new
> feature. (Also, I might have trust issues with DNS due to several past
> production disasters.)
On 09.08.23 08:42, Laetitia Avrot wrote:
I agree that the feature I'm suggesting could be done with a few tricks.
I meant to simplify the life of the user by providing a simple new
feature. (Also, I might have trust issues with DNS due to several past
production disasters.)
My question is ver
Dear all,
First, thank you so much for your interest in this patch. I didn't think I
would have so many answers.
I agree that the feature I'm suggesting could be done with a few tricks. I
meant to simplify the life of the user by providing a simple new feature.
(Also, I might have trust issues wi
Hi,
## Laetitia Avrot (laetitia.av...@gmail.com):
> 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
Le jeu. 3 août 2023 à 15:17, Christoph Moench-Tegeder
a écrit :
> ## Laetitia Avrot (laetitia.av...@gmail.com):
>
> > 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.
## Laetitia Avrot (laetitia.av...@gmail.com):
> 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
Le jeu. 3 août 2023 à 14:20, <066ce...@free.fr> a écrit :
>
>
> > Agreed, depending on how hosts and dns are set, it can be useless.
> > But normally, companies have host making standards to avoid that.
>
>
> BTW you already have it :
>
> select setting from pg_settings where name = 'listen_addres
> Agreed, depending on how hosts and dns are set, it can be useless.
> But normally, companies have host making standards to avoid that.
BTW you already have it :
select setting from pg_settings where name = 'listen_addresses'
No ?
Le jeu. 3 août 2023, 11:31, Matthias van de Meent <
boekewurm+postg...@gmail.com> a écrit :
> On Thu, 3 Aug 2023 at 10:37, Laetitia Avrot
> wrote:
> >
> > Dear Hackers,
> >
> > One of my customers suggested creating a function that could return the
> server's hostname.
>
> Mostly for my curiosity
On Thu, 3 Aug 2023 at 10:37, Laetitia Avrot wrote:
>
> Dear Hackers,
>
> One of my customers suggested creating a function that could return the
> server's hostname.
Mostly for my curiosity: What would be their use case?
I only see limited usability, considering that the local user's
hostname ca
Dear Hackers,
One of my customers suggested creating a function that could return the
server's hostname.
After a quick search, we found [this Wiki page](
https://wiki.postgresql.org/wiki/Pg_gethostname) referring to [that
extension](https://github.com/theory/pg-hostname/) from David E. Wheeler.
19 matches
Mail list logo
