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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
