SQL pattern matching: Choose the accurate statement. “In SQL-92, the wildcard asterisk (*) represents any sequence of characters.”

Difficulty: Easy

Correct Answer: Incorrect

Explanation:


Introduction / Context:
Pattern matching in standard SQL uses the LIKE operator with specific wildcard symbols. Confusing these symbols (especially across tools and shells) leads to wrong results and puzzling bugs. This question checks whether you know the standard wildcard for “any sequence of characters.”



Given Data / Assumptions:

  • ANSI SQL-92 semantics for LIKE are assumed.
  • We are not discussing filesystem globbing or vendor-specific regex functions.
  • Simple character and pattern comparisons with LIKE are in scope.


Concept / Approach:
In SQL-92, LIKE uses the percent sign % to match any sequence of zero or more characters and the underscore _ to match exactly one character. The asterisk * is not the standard wildcard in LIKE. Some tools (for example, legacy Access modes or GUI filters) may accept * as a convenience, but this is not the ANSI standard. Conflating shell globbing (where * matches any sequence) with SQL LIKE is a frequent misconception.



Step-by-Step Solution:

Recall the rules: % = any sequence; _ = single character.Construct an example: WHERE name LIKE 'Jo%' matches John, Jose, Jo.Test with : WHERE name LIKE 'Jo' will not behave as intended under ANSI SQL (it may error or treat * literally).Therefore, the statement that * is the SQL-92 wildcard for sequences is false.


Verification / Alternative check:
Vendor documentation (PostgreSQL, SQL Server, MySQL in SQL mode) confirms % and _ are the LIKE wildcards; * is used in SELECT * to mean “all columns,” not for pattern matching.



Why Other Options Are Wrong:

  • “Correct” contradicts the standard.
  • “Correct only in MS Access” is out of scope for SQL-92 and still not the standard.
  • “Applies only to REGEXP” mixes regex syntax with LIKE semantics.
  • “Depends on collation” affects comparison rules, not wildcard characters.


Common Pitfalls:
Using filesystem instincts in SQL; forgetting to escape % or _ when matching them literally (via ESCAPE clause).



Final Answer:
Incorrect

More Questions from Introduction to SQL

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion