I do indeed see this behavior in some very quick testing using 9.3
David Fetter wrote
> I've noticed that psql's \c function handles service= requests in a
> way that I can only characterize as broken.
Looking at the docs the fact it attempts to treat "service=foo" as anything
other than a database name is broken...
> 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 has a few possible final implementations to consider given that both \c
and service= can be incompletely specified and what happens if both \c-host
and service-host, for instance, are specified...but I'm not in a position to
reason out the various possibilities right now. Regardless, the ability to
specify a service name is valuable (if one presumes \c is valuable) so the
tasks are finding an implementer and, depending on that outcome, how to
handle back-branches.
I don't think the status-quo is safe enough to leave so for head either #1
or #2 get my vote. Leaving it broken in back branches is not appealing but
maybe we can selectively break it if we cannot get a #2 implementation that
can be back-patched.
An aside - from the docs: "If there is no previous connection [...]" - how
is this possible when issuing \c?
David J.
--
View this message in context: http://postgresql.nabble.com/POLA-violation-with-c-service-tp5831001p5831026.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
