From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
Subject: Re: Bug or intentionally under-documented "\c databasename;"
 behavior?
In-reply-to: 
 <CAKFQuwYwWh9wNWxbFAc_9apovbRo9Sfe8jRM7Mf98C8Tn2dE9A@mail.gmail.com>
References: 
 <CAKFQuwYwWh9wNWxbFAc_9apovbRo9Sfe8jRM7Mf98C8Tn2dE9A@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Fri, 25 Nov 2022 08:50:57 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4059187.1669392529.1@sss.pgh.pa.us>
Date: Fri, 25 Nov 2022 11:08:49 -0500
Message-ID: <4059188.1669392529@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4059188.1669392529%40sss.pgh.pa.us>
Precedence: bulk

"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