Note: Scenarios to successfully execute your SQL statements

You must understand the following scenarios to successfully execute your SQL statements:

Scenario 1: Executing SQL statements without expressions

If the expression toggle of the SQL statement field is not selected:

• The SQL statement must not be within quotes.
• The $<variable_name> parts of the SQL statement are expressions. In the below example, $id and $book.

Example:

INSERT INTO books VALUES ($id, $book)

Additionally, the JSON path (e.g. $myName) is allowed only in the WHERE clause.

If the SQL statement starts with SELECT (case-insensitive), the Snap regards it as a select-type query and executes once per input document. If not, it regards it as write-type query and executes in batch mode.

Scenario 2: Executing SQL queries with expressions

If the expression toggle of the SQL statement field is selected:

• The SQL statement must be within quotes.
• The + $<variable_name> + parts of the SQL statement are expressions, and must not be within quotes. In the below example, $tablename.
• The $<variable_name> parts of the SQL statement is bind parameter and must be within quotes. In the below example, $id and $book.

Note: Table name and column names must not be provided as bind parameters. Only values can be provided as bind parameters.

Example:

"INSERT INTO " + $tablename + " VALUES ($id, $book)"

Note: We recommend you to add a single query in the SQL Statement field.

Note: Known Issues

• When the SQL statement property is an expression, the Pipeline parameters are shown in the suggest, but not the input schema.

The non-expression form uses bind parameters, so it is much faster than executing N arbitrary SQL expressions.

Note:

• The SQL statement will return a PGObject when returning non-standard types.

Note:

• Non-standard types include standard PostgreSQL extensions such as JSON or XML, types defined in third party extensions such as PostGIS, or types defined via CREATE TYPE color AS ENUM (RED, GREEN, BLUE). They can be converted to strings using CAST(x AS TEXT) where 'x' is the name of the column.
• The '$' sign and identifier characters, such as double quotes ("), single quotes ('), or back quotes (`), are reserved characters and should not be used in comments or for purposes other than their originally intended purpose.

Note: When you set the Number of retries to more than 0, the Snap generates duplicate records when the connection is not established. To prevent duplicate records, we recommend that you follow one of the following:

• Set the Number of retries to 0 (default value) to prevent duplicate records from being passed downstream while executing a pipeline.
• Use a Primary key to prevent records from being inserted into the database.
• Use an Upsert instead of an Insert statement.

Note: 'Auto commit' may be enabled for certain use cases if PostgreSQL jdbc driver is used in either Redshift, PostgreSQL or generic JDBC Snap. But the JDBC driver may cause out of memory issues when Select statements are executed. In those cases, "Auto commit" in Snap property should be set to 'False' and the Fetch size in the "Account setting" can be increased for optimal performance.

Note: Behavior of DML Queries in Database Execute Snap when auto-commit is false

DDL queries used in the Database Execute Snap will be committed by the Database itself, regardless of the Auto-commit setting.

When Auto commit is set to false for the DML queries, the commit is called at the end of the Snap's execution.

The Auto commit needs to be true in a scenario where the downstream Snap does depend on the data processed on an Upstream Database Execute Snap containing a DML query.

When the Auto commit is set to the Use account setting on the Snap, the account level commit needs to be enabled.