Experiencing different behavior on multiple environments when using AppSync with RDS (Aurora PostgreSQL)

I have been using AWS CDK to deploy a BE stack that consists of mainly AppSync + RDS (Aurora PostgreSQL v11_16 Serverless) into several environments. I had an example mutation where I would insert a string value (AWSEmail) email and a timestamp value (AWSDateTime) subscribedUntil into a table accordingly. I've made this using a UNIT VTL resolver, here's the request mapping template:

{
    "version": "2018-05-29",
    "statements": [
        $util.toJson("INSERT INTO ""Users"" (email, ""subscribedUntil"") VALUES (:email, :subscribedUntil)"),
        $util.toJson("SELECT * FROM ""Users"" WHERE email = :email")
    ],
    "variableMap": {
        ":email": $util.toJson($ctx.args.input.email),
        ":subscribedUntil": $util.toJson($ctx.args.input.subscribedUntil)
    }
}

As mentioned at the very end of this documentation the variable map simply concatenates the variables into the SQL statements for the RDS to execute, so it just makes things more readable.

This expected behavior is actually happening in two of my environments, but when I tried creating a new third environment and deploy same resources with the same configurations using CDK, the mutation behaved differently.

How different? Well, it seems that AppSync didn't just concatenate these variables into the SQL statements, instead it somehow made them into parameters, and made it as what I would call a prepared statement(?)

I extracted the logs of that mutation's execution from the RDS for the different environments:

1st and 2nd env: received the first statement for example as: INSERT INTO "Users" (email, "subscribedUntil") VALUES ('test@test.com', '2023-05-05T04:00:00.000Z') so as expected, concatenates the values coming from the variable map into the statement correctly.
the 3rd or any other new env that I would create (even manually without CDK): received the first statement as: INSERT INTO "Users" (email, "subscribedUntil") VALUES ($1, $2) so it turns them into params that it would (I would assume) prepare the statement with, in the following steps (in the background):
```
PREPARE testplan (varchar, varchar) AS
INSERT INTO "Users" VALUES($1, $2);
EXECUTE testplan('test@test.com', '2023-05-05T04:00:00.000Z');
```

What's wrong with this parametrization of the statements? Other than the fact that this is different from the documented behavior, it makes it that those supplied values are passed as VARCHAR params into the statements, so that now RDS is erroring out that values are supplied as VARCHAR when the subscribedUntil column is expecting a timestamp:

"RDSHttp:{\"message\":\"ERROR: column \\\"subscribedUntil\\\" is of type timestamp with time zone but expression is of type character varying\\n  Hint: You will need to rewrite or cast the expression.\\n  Position: 60; SQLState: 42804\"}"

I'm thinking that the expected behavior (in 1st and 2nd) concatenated them into the statements, having them wrapped with single quotes made them of type unspecified or unknown, so that SQL figured out their types based on the columns they were being inserted into? but on the other environment (3rd or new ones) would have them explicitly parameterized as VARCHARs

Questions:

Were there any changes related to AppSync that would cause such parametrization?
How can I make sure that all my environments would have the same behavior in terms of the communication between AppSync and RDS other than using CDK to define every resource and configurations?
What's the best way to map values into statements?
Should I always explicitly cast the values being passed into SQL statements with their intended types?

aws / aws-appsync-community

Experiencing different behavior on multiple environments when using AppSync with RDS (Aurora PostgreSQL) #284