On Mon, Sep 20, 2021 at 08:26:51PM +0100, Dagfinn Ilmari Mannsåker wrote: > Daniel Gustafsson <dan...@yesql.se> writes: > > > While testing a patch I fat-fingered a CREATE DATABASE statement by tab > > completing *after* the semicolon, with no space between the objname and > > semicolon. The below options were presented, which at this point aren't > > really > > applicable: > > > > db=# create database foo; > > ALLOW_CONNECTIONS ENCODING LC_COLLATE LOCALE > > TABLESPACE > > CONNECTION LIMIT IS_TEMPLATE LC_CTYPE OWNER > > TEMPLATE > > > > DROP DATABASE has a similar tab completion which makes about as much sense: > > > > db=# drop database foo;WITH ( > > > > Checking prev_wd for not ending with ';' as per the attached makes > > "objname;" > > behave like "objname ;". Is there a reason for not doing that which I'm > > missing? I didn't check for others, but if this seems reasonable I'll go > > through to find any other similar cases. > > The same applies to any completion after a MatchAny that ends in a any > of the WORD_BREAKS characters (except whitespace and () which are > handled specially). > > #define WORD_BREAKS "\t\n@$><=;|&{() " > > IMO a fix should be more principled than just special-casing semicolon > and CREATE TABLE. Maybe get_previous_words() should stop when it sees > an unquoted semicolon?
Is there some reason get_previous_words() shouldn't stop for everything that's WORD_BREAKS? If not, making that the test might make the general rule a little simpler to write, and if WORD_BREAKS ever changed, for example to include all space, or all breaking space, or similar, the consequences would at least not propagate through seemingly unrelated code. At the moment, get_previous_words() does look for everything in WORD_BREAKS, and then accounts for double quotes (") and then does something clever to account for double quotes and the quoting behavior that doubling them ("") accomplishes. Anyhow, that looks like it should work in this case, but clearly it's not. Would it be less error prone to do these checks and maybe push or pop one or more stacks holding state as each character came in? I suspect the overhead would be unnoticeable even on the slowest* client. Best, David. * One possible exception would be a gigantic paste, a case where psql can be prevented from attempting tab completion, although the prevention measures involve a pretty obscure terminal setting: https://cirw.in/blog/bracketed-paste Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate