Re: removal of '{' from WORD_BREAKS

Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> On Tue, Apr 9, 2024 at 6:18 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I too felt uneasy about that commit, for the same reason. However,
>> there is a justification for the change in the commit message which is
>> not obviously wrong, namely that ":{?name} is the only psql syntax
>> using the '{' sign". And in fact, SQL basically doesn't use '{' for
>> anything, either.

True.

> FWIW, the default value of rl_basic_word_break_characters [1] has '{'
> but doesn't have '}'. The documentation says that this should "break
> words for completion in Bash". But I failed to find an explanation
> why this should be so for Bash. As you correctly get, my idea was
> that our SQL isn't not heavily using '{' unlike Bash.

Yeah, there's no doubt that what we are currently using for
WORD_BREAKS has mostly been cargo-culted from Bash rather than having
any solid foundation in SQL syntax. It works all right for us today
because we don't really try to complete anything in general SQL
expression contexts, so as long as we have whitespace and parens in
there we're more or less fine.

I wonder a bit why comma isn't in there, though. As an example,
vacuum (full,fre<TAB>
fails to complete "freeze", though it works fine with a space
after the comma. I've not experimented, but it seems certain
that it'd behave better with comma in WORD_BREAKS. Whether
that'd pessimize other behaviors, I dunno.

The longer-range concern that I have is that if we ever want to
complete stuff within expressions, I think we're going to need
all the valid operator characters to be in WORD_BREAKS. And that
will be a problem for this patch, not because of '{' but because
of '?'. So I'd be happier if the parsing were done in a way that
did not rely on '{' and '?' being treated as word characters.
But I've not looked into how hard that'd be. In any case, it's
likely that expanding WORD_BREAKS like that would cause some other
problems that'd have to be fixed, so it's not very reasonable to
expect this patch to avoid a hypothetical future problem.

regards, tom lane