From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Thoughts on a "global" client configuration? |
Date: | 2025-10-15 19:20:31 |
Message-ID: | 4a2daa3b-9fd7-4453-bb44-b127e5aa8b9f@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-10-15 19:21:50 | Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward |
Previous Message | Andrew Dunstan | 2025-10-15 19:10:03 | Re: [PATCH] Add pg_get_trigger_ddl() to retrieve the CREATE TRIGGER statement |