Re: Thoughts on a "global" client configuration? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Thoughts on a "global" client configuration?
Date
Msg-id 4a2daa3b-9fd7-4453-bb44-b127e5aa8b9f@eisentraut.org
Whole thread Raw
In response to Thoughts on a "global" client configuration?  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: Thoughts on a "global" client configuration?
Re: Thoughts on a "global" client configuration?
List pgsql-hackers
On 06.10.25 20:05, Jacob Champion wrote:
> I started on a proof of concept and very quickly hit a fork. Do I
> 1) introduce a completely new config file, or
> 2) adapt pg_service.conf to this use case?

I've been thinking about this kind of thing for a long time, and my 
intuition has always been to have some kind of [default] section in 
pg_service.conf.  That would probably be relatively easy.

But:

> - backwards and forwards compatibility (we don't ever break old
> libpqs, but new libpqs can add new options safely)

It might be worth elaborating exactly how this would be solved.  If I 
look through my dotfiles history, this kind of thing has been a 
perennial problem.  I don't have any specific ideas right now -- other 
than perhaps "ignore unknown parameters", which is surely not without 
problems.  Depending on what we'd settle on here, that might inform 
whether it's feasible to stick this into pg_service.conf or whether it 
needs to be a separate thing.




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCH] Add pg_get_trigger_ddl() to retrieve the CREATE TRIGGER statement
Next
From: Tom Lane
Date:
Subject: Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward