Alexander Korotkov <aekorot...@gmail.com> writes: > On Tue, Apr 9, 2024 at 6:18 PM Robert Haas <robertmh...@gmail.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