| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | PostgreSQL Bug List <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Bug or intentionally under-documented "\c databasename;" behavior? |
| Date: | 2022-11-25 16:08:49 |
| Message-ID: | 4059188.1669392529@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-11-25 17:06:15 | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
| Previous Message | David G. Johnston | 2022-11-25 15:50:57 | Bug or intentionally under-documented "\c databasename;" behavior? |