Member Junction
    Preparing search index...
    • Whether fragment, a WHERE-clause expression a caller supplied, stays inside one pair of parentheses put around it. Code that builds (<fragment>) AND (<server filter>) depends on this: a fragment such as 1=1) OR (1=1 closes the parentheses early, so the server filter narrows only one side of an OR the fragment controls.

      The fragment is read with the dialect's lexer (LexSQL), so a parenthesis inside a string literal, quoted identifier or comment does not count. Text the lexer may not read the way the database does is refused rather than guessed at. The fragment is refused when it:

      • ends inside a string literal, quoted identifier or comment, which would take in the SQL that follows it;
      • contains a comment, unless BalancedFragmentOptions.AllowComments is set;
      • closes a parenthesis it did not open, or leaves one open;
      • contains a statement separator (;);
      • on PostgreSQL (a dialect with escape or dollar-quoted strings):
        • has a character outside ASCII anywhere but inside a string literal, quoted identifier or comment. PostgreSQL reads every such character as part of a name, Unicode spaces included; the lexer does not;
        • has a dollar-quoted string, or a $ anywhere but inside a name;
        • follows an escape string (E'…') with another string literal. PostgreSQL joins literals that a line break separates and reads the second in escape mode; the lexer reads it as plain;
        • puts a string directly after a name that contains @ or #, or after a number ending in e. The lexer reads @ and # as name characters, but PostgreSQL reads them as operators (and splits 1e before a quote).

      Parameters

      Returns BalancedFragmentCheck