Re: [PATCH] support tab-completion for single quote input with equal sign

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] support tab-completion for single quote input with equal sign
Date: 2021-09-04 14:18:24
Message-ID: 2696375.1630765104@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com> writes:
> [ v2-0001-support-tab-completion-for-single-quote-input-wit.patch ]

Surely this patch is completely wrong? It needs more thought about
the interaction with the existing logic for double quotes, ie single
quote inside double quotes is not special, nor the reverse; nor should
parentheses inside quotes be counted. It also needs to be aware of
backslashes in escape-style strings.

I kind of doubt that it's actually possible to parse string literals
correctly when working backward, as this function does. For starters,
you won't know whether the string starts with "E", so you won't know
whether backslashes are special. We've got away with backwards
parsing so far because the syntax rules for double-quoted strings are
so much simpler. But if you want to handle single quotes, I think
you'll have to start by rearranging the code to parse forward. That's
likely to be fairly ticklish, see the comment about

* backwards scan has some interesting but intentional properties
* concerning parenthesis handling.

I wish that whoever wrote that (which I think was me :-() had been
more explicit. But I think that the point is that we look for a place
that's at the same parenthesis nesting level as the completion point,
not necessarily one that's globally outside of any parens. That will
be messy to handle if we want to convert to scanning forwards from
the start of the string.

I kind of wonder if it isn't time to enlist the help of psqlscan.l
instead of doubling down on the idea that tab-complete.c should have
its own half-baked SQL lexer.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-09-04 14:41:04 Re: Column Filtering in Logical Replication
Previous Message Andrew Dunstan 2021-09-04 13:58:08 Re: Postgres perl module namespace