What is a characteristic of the use of binding variables in JavaScript stored procedures in Snowflake?

Question

Options

• AAll types of JavaScript variables can be bound.
• BAll Snowflake first-class objects can be bound.
• COnly JavaScript variables of type number, string, and SfDate can be bound.
• DUsers are restricted from binding JavaScript variables because they create SQL injection attack

• B
  4% (1)
• C
  93% (25)
• D
  4% (1)

Explanation

In Snowflake JavaScript stored procedures, binding variables to SQL statements is intentionally restricted to only three JavaScript types: number, string, and SfDate - these map cleanly to Snowflake's core SQL data types, making type conversion safe and predictable. Option A is wrong because JavaScript has many types (objects, arrays, booleans, etc.) that cannot be bound. Option B is wrong because Snowflake "first-class objects" (like stages, databases, or schemas) are not bindable values - they're structural identifiers, not data parameters. Option D is wrong on two counts: binding is actually allowed, and it's the opposite of a security risk - binding variables is the defense against SQL injection, not a cause of it.

Memory tip: Think "NSD" - Number, String, Date (SfDate). If the JavaScript type isn't one of these three primitives, it can't be bound in a Snowflake stored procedure.

No community discussion yet for this question.