Re: POLA violation with \c service=
От | Heikki Linnakangas |
---|---|
Тема | Re: POLA violation with \c service= |
Дата | |
Msg-id | 549148C3.8090003@vmware.com обсуждение исходный текст |
Ответ на | Re: POLA violation with \c service= (Albe Laurenz <laurenz.albe@wien.gv.at>) |
Ответы |
Re: POLA violation with \c service=
|
Список | pgsql-hackers |
On 12/17/2014 10:03 AM, Albe Laurenz wrote: > David Fetter wrote: >> I've noticed that psql's \c function handles service= requests in a >> way that I can only characterize as broken. >> >> This came up in the context of connecting to a cloud hosting service >> named after warriors or a river or something, whose default hostnames >> are long, confusing, and easy to typo, so I suspect that service= may >> come up more often going forward than it has until now. >> >> For example, when I try to use >> >> \c "service=foo" >> >> It will correctly figure out which database I'm trying to connect to, >> but fail to notice that it's on a different host, port, etc., and >> hence fail to connect with a somewhat unhelpful error message. >> >> I can think of a few approaches for fixing this: >> >> 0. Leave it broken. >> 1. Disable "service=" requests entirely in \c context, and error out if attempted. >> 2. Ensure that \c actually uses all of the available information. >> >> Is there another one I missed? >> >> If not, which of the approaches seems reasonable? > > #2 is the correct solution, #1 a band aid. It would be handy, if \c "service=foo" actually worked. We should do #3. If the database name is actually a connection string, or a service specification, it should not re-use the hostname and port from previous connection, but use the values from the connection string or service file. - Heikki
В списке pgsql-hackers по дате отправления: