Wildcard usage enhancements in .pgpass

Поиск
Список
Период
Сортировка
От Alexey Klyukin
Тема Wildcard usage enhancements in .pgpass
Дата
Msg-id CAAS3tyKHjqkWfMzA+T9U32QSRo8OHwNx+m3NeTzgJAKt_uVhHw@mail.gmail.com
обсуждение исходный текст
Ответы Re: Wildcard usage enhancements in .pgpass  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Hi,

Attached is the patch that improves usage of '*' wildcard in .pgpass, particularly in the host part. The use case is below.

I work with multiple environments (like staging, production, performance and so on), each one containing tens of different database clusters, each cluster has its own subdomain in DNS, i.e. foo.test.db, bar.test.db and so on. Each user has the same credentials on every database of a single domain, i.e. .test.db databases, but different ones in other domains. For those databases, each line in pgpass currently corresponds to a single database, i.e.

foo1.test.db:5432:postgres:postgres:keep!tester
foo2.test.db:5432:postgres:postgres:keep!tsecret
...
foo99.test.db:5432:postgres:postgres:keep!tsecret
....
bar1.another.db.:5432:postgres:postgres:trustno1
bar2.another.db.:5432:postgres:postgres:trustno1
...

The problem I'm having is that there are just too many lines like those (tens or even hundreds) and the new databases are added very frequently, making it hard to keep .pgpass up-to-date.

What I'd like to have is an ability to specify a pattern in the hostname of .pgpass, to replace the plenty of lines with one:

*.test.db:5432:postgres:postgres:keep!secret
bar*.*.db:5432:postgres:postgres:trustno1

The patch in attachment implements exactly this, by allowing '*' in the hostname to substitute arbitrary number of characters until the dot. The pattern is only matched when there is a '.' or ':' after the * and only in the hostname, otherwise, '*' is treated like a normal character. It appears that it can only be used for IPv4 addresses, i.e. instead of 255 hosts for 192.168.1.0/24  one can just specify 192.168.1.*.

I do understand that it might be a very limited use case in terms of community plans for improving .pgpass, but I doubt that I'm the only one to stumble upon the current limitation; the patch is quite small and might be the first step into extending the functionality of .pgpass

It's currently missing the documentation, which I will add in case there will be an interest in making this patch a part of the core.

Your feedback is greatly appreciated.

--
Regards,
Alexey Klyukin

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Review:Patch: SSL: prefer server cipher order
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: pre-commit triggers