On Wed, Dec 17, 2014 at 8:25 AM, David Fetter [via PostgreSQL] < ml-node+s1045698n5831124...@n5.nabble.com> wrote:
> 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. > > letting libpq handle this is the only sane plan for fixing it. I'm > looking into that today. > > On a tangentially related note; it is not outside the realm of possibility that a user would want one pg_service entry to reference another one: [realentry] user= dbname= [aliasentry] service=realentry furthermore, having a shareable entry like: [main-host] host=ip-address port=5433 [main-user1] user=user1 service=main-host [main-user2] user=user2 service=main-host also seems potentially useful. I just sent a -doc report that nothing in the documentation says this behavior is not implemented but a cursory attempt at it confirms the lack. While you are digging in there anything fundamental prohibiting the behavior and is it something you think would be useful in these complex environments you are working with? David J. Sorry about the oddball CC: but I don't have an e-mail with a full set of recipients... -- View this message in context: http://postgresql.nabble.com/POLA-violation-with-c-service-tp5831001p5831538.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
