Обсуждение: Bug or intentionally under-documented "\c databasename;" behavior?
Hey,
I expected the following to tell me: database "testdb;" does not exist
Instead the connection attempt was successful.
postgres=# create database testdb;
CREATE DATABASE
postgres=# \c testdb;
You are now connected to database "testdb" as user "vagrant".
CREATE DATABASE
postgres=# \c testdb;
You are now connected to database "testdb" as user "vagrant".
Specifically, the trailing semi-colon on the testdb is being treated, apparently, as a second parameter to \c (or just plain ignored which seems wrong too); which itself is a surprise given the absence of whitespace, and \c documents that - passed as a parameter is an acceptable way to omit a parameter so the semi-colon should have been considered as a username.
David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes: > I expected the following to tell me: database "testdb;" does not exist > Instead the connection attempt was successful. > postgres=# create database testdb; > CREATE DATABASE > postgres=# \c testdb; > You are now connected to database "testdb" as user "vagrant". This is because psql_scan_slash_option was told to strip any trailing semicolon, and did so. If there's any rhyme or reason to which psql metacommands pass semicolon=true and which do not, I can't detect it :-(. And you're right that there's nothing about it in the documentation. I wonder if we can get away with removing that quirk. Or else try to establish some policy about it, and document the policy. A really brave person might propose nuking the OT_SQLIDHACK parsing mode as well. That was never supposed to be a long-term fixture. regards, tom lane