Database policy support for PUT/PATCH operations - PostgreSQL

[ArjunNarendra]

Why make this change?

As per the behaviour expected from PUT/PATCH operations with database policies discussed in #1430, implement db policy support for PostgreSQL to fix #1372.

What is this change?

1. Prior to this change, there was only one database policy for each operation. Since now database policies will be supported for both insert (or create)/update actions via PUT/PATCH operations, these 2 operations can have 2 database policies defined for them, one for each action.

2. The query generated by PostgresQueryBuilder.Build(SqlUpsertQueryStructure structure) is modified to accommodate create/update policies while also keeping intact the normal upsert behavior expected (try update, then insert).

3. The method IQueryExecutor.GetMultipleResultSetsIfAnyAsync has been provided another implementation specific to PostgreSql in PostgreSqlExecutor. The DbDataReader instance for the query being executed for the PUT/PATCH operation will always contain two result sets.

4. Different scenarios are added to the method PostgreSqlExecutor.GetMultipleResultSetsIfAnyAsync to throw appropriate exceptions (Forbidden/Authorization failure - 403 and NotFound - 404). Appropriate comments are added within the code to demonstrate each case.

How was this tested?

Integration Tests - Done

[Copilot]

Pull request overview

This PR extends PostgreSQL PUT/PATCH (upsert) behavior to correctly apply database policies for both the update and insert branches, aligning Postgres behavior with the expected policy semantics for REST upserts.

Changes:

• Updated PostgreSQL upsert SQL generation to evaluate update-policy vs create-policy depending on which branch executes, while preserving “try update then insert” semantics.
• Added a PostgreSQL-specific GetMultipleResultSetsIfAnyAsync implementation to interpret multi-result-set upsert outcomes and return 403/404 appropriately.
• Updated PostgreSQL REST integration tests and test config to exercise create-policy behavior for PUT/PATCH insert cases.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Service.Tests/SqlTests/RestApiTests/Put/PostgreSqlPutApiTests.cs	Adds expected SQL for PUT insert-with-policy and removes ignored overrides so tests run.
src/Service.Tests/SqlTests/RestApiTests/Patch/PostgreSqlPatchApiTests.cs	Adds expected SQL for PATCH insert-with-policy and removes ignored overrides so tests run.
src/Service.Tests/dab-config.PostgreSql.json	Adds a PostgreSQL create-action database policy used by the new PUT/PATCH scenarios.
src/Core/Resolvers/SqlMutationEngine.cs	Passes additional context into the result-set handler for upsert result interpretation.
src/Core/Resolvers/PostgresQueryBuilder.cs	Reworks PostgreSQL upsert SQL to support separate create/update policies and emit a PK-existence count result set.
src/Core/Resolvers/PostgreSqlExecutor.cs	Implements PostgreSQL-specific multi-result-set handling to map policy failures vs not-found.
src/Core/Configurations/RuntimeConfigValidator.cs	Allows PostgreSQL to define create-action database policies in config validation.
config-generators/postgresql-commands.txt	Updates generator commands to set separate create/read permissions and the new create policy.

[ArjunNarendra]

So it looks like all the automated tests in Azure pipelines are passing now but at one point one of the Cosmos tests was failing. Specifically, one of the tests in the TestTimePartitionedSampler test method in the SamplerTests.cs test class was failing with the following error: Assert.IsTrue failed. Expected result count is 10 and Actual result count is 8. The specific data row that was causing this failure was [DataRow(null, 1, 0, 10, DisplayName = "Retrieve 10 records, if 1 item is allowed to fetch from each group and number of groups is 10 (i.e default)")]. So it was passing before until I merged the main upstream branch into my feature branch which is odd because it would suggest that the changes pushed to main were breaking the test or some weird interaction between the changes in the feature branch and the new changes in main were breaking the test. I tried to rerun the failing test suites but that particular test was still failing. Then, I converted this PR to a draft and then reconverted it back to a 'ready for review' state. That seemed to have done the trick and now all the test suites are passing. Therefore, I am not even sure what caused that one Cosmos test to fail in the first place; I think it can be chalked up to some flakiness in the environment or inconsistencies in the Azure Pipelines environment.