On Wed, Mar 4, 2015 at 8:33 AM, David Fetter <da...@fetter.org> wrote: > On Tue, Mar 03, 2015 at 09:52:55PM -0500, Robert Haas wrote: >> On Mon, Mar 2, 2015 at 5:05 PM, David Fetter <da...@fetter.org> wrote: >> > So just to clarify, are you against back-patching the behavior >> > change, or the addition to src/common? >> >> Mostly the latter. > > So you're saying the former isn't a problem? To recap, the behavior I > dug up was that sending a conninfo string or a URI to \c resulted in > \c's silently mangling same in a way that could only work accidentally.
Well, the thing is, I'm not sure that's actually documented to work anywhere. psql says this: \c[onnect] [DBNAME|- USER|- HOST|- PORT|-] The psql documentation looks like this: \c or \connect [ dbname [ username ] [ host ] [ port ] ] Neither says anything about being able to use a conninfo string or a URI. So I am not sure why we shouldn't regard this as a new feature --- which, by the way, should be documented. Arguably the right thing to do is back-patch a change that prevents the dbname from being interpreted as anything other than a literal database name, and then in master make it work as you suggest. Now, if those two patches are substantially equal in size and risk, then you could argue that's just silly, and that we should just make this work all the way back. I'm willing to accept that argument if it is in fact true. But I'm not very excited about doing what amounts to a refactoring exercise in the back-branches. Shuffling code around from one file to another seems like something that we really ought to only be doing in master unless there's a really compelling reason to do otherwise, and making something work that is not documented to work does not compel me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers