Re: POLA violation with \c service=
| От | David Fetter |
|---|---|
| Тема | Re: POLA violation with \c service= |
| Дата | |
| Msg-id | 20141231004811.GA25019@fetter.org обсуждение исходный текст |
| Ответ на | Re: POLA violation with \c service= (Andrew Dunstan <andrew@dunslane.net>) |
| Ответы |
Re: POLA violation with \c service=
|
| Список | pgsql-hackers |
On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote: > > On 12/17/2014 04:11 AM, Heikki Linnakangas wrote: > >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. > > Yeah, that's the correct solution. It should not be terribly difficult to > create a test for a conninfo string in the dbname parameter. That's what > libpq does after all. We certainly don't want psql to have to try to > interpret the service file. psql just needs to let libpq do its work in this > situation. This took a little longer to get time to polish than I'd hoped, but please find attached a patch which: - Correctly connects to service= and postgres(ql)?:// with \c - Disallows tab completion in the above cases I'd like to see about having tab completion actually work correctly in at least the service= case, but that's a matter for a follow-on patch. Thanks to Andrew Dunstan for the original patch, and to Andrew Gierth for his help getting it into shape. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Вложения
В списке pgsql-hackers по дате отправления: