Re: POLA violation with \c service=

On Fri, Dec 19, 2014 at 07:03:36PM -0700, David Johnston wrote:
> 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​:

You want entries in the service system to be able reference other
entries, setting defaults, for example? Interesting idea. As you
say, it's tangential to this.

The bug I found, and I'm increasingly convinced it's a bug whose fix
should be back-patched, is that psql fails to let libpq do its job
with the extant service system, or more precisely prevents it from
doing only part of its job, leading to broken behavior.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate