Re: POLA violation with \c service=

On Wed, Dec 17, 2014 at 8:25 AM, David Fetter [via PostgreSQL] <
ml-node+s1045698n5831124h68(at)n5(dot)nabble(dot)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.