Add support for DateTime filters in PostgreSQL

[ArjunNarendra]

Why make this change?

This pull request is to address #3094, which is a bug that happens because certain date/time SQL parameters are not being parsed to their appropriate .NET type (DateTime or DateTimeOffset) and are instead being treated as raw text. This is leading to type conversion issues when executing the underlying SQL query.

What is this change?

I have provided an overridden implementation of MakeDbConnectionParam in BaseSqlQueryStructure.cs. This method does some extra pre-processing for PostgreSQL parameters specifically by parsing each parameter into its appropriate system type before calling the base class implementation of MakeDbConnectionParam in BaseQueryStructure.cs. The system type of each parameter is retrieved from metadata of the underlying column that this parameter corresponds to via the method GetColumnSystemType. This change fixes the relevant issue because now parameters which correspond to an underlying datetime column in the schema are cast to their appropriate .NET type instead of falling through as text before building the final SQL query. Furthermore, this change is limited in scope to apply this parameter casting only when the underlying database is PostgreSQL. This ensures we do not see unexpected behavior with other database types where this sort of parameter casting may be unnecessary and/or erroneous.

My original thought was to modify the method ExtractValueFromIValueNode in ExecutionHelper.cs to explicitly handle an IValueNode with a GraphQL scalar type of SupportedHotChocolateTypes.DATETIME_TYPE by parsing the IValueNode as a DateTime system type before being returned. For all practical purposes, this has the same desired effect as parsing the parameter in MakeDbConnectionParam, but the call to ExtractValueFromIValueNode happens upstream of the call to MakeDbConnectionParam.

I believe that casting the parameters to their appropriate .NET type in MakeDbConnectionParam is appropriate because the method literally builds each parameter for the SQL query and the .NET type casting can be considered a part of this parameter building process. I do not think .NET type casting is as appropriate in ExtractValueFromIValueNode because this method serves the broader purpose of extracting a value from a GraphQL IValueNode, where the IValueNode could contain a scalar but it could also contain a variable that needs to be resolved recursively. For parameters that need to be cast to a .NET type, the control flow will go from ExtractValueFromIValueNode to eventually MakeDbConnectionParam, but again, MakeDbConnectionParam serves the sole purpose of building the parameter while ExtractValueFromIValueNode serves a broader purpose.

How was this tested?

• [ X] Integration Tests

Sample Request(s)

With query:

query {
  assignments(filter: { assignment_due_date: { gte: "2026-03-23T00:00:00.000Z" } }) {
    items {
      assignment_id
      assignment_name
      assignment_due_date
    }
  }
}

Before:

SELECT * FROM public."Assignments"
WHERE "Assignments"."assignment_due_date" >= '2026-03-23T00:00:00.000Z'::text;

After:

SELECT * FROM public."Assignments"
WHERE "Assignments"."assignment_due_date" >= '2026-03-23T00:00:00.000Z';

[Copilot]

Pull request overview

This PR aims to fix PostgreSQL GraphQL filter failures for date/time columns (issue #3094) by ensuring filter parameter values are converted from raw GraphQL string values into the appropriate .NET types (DateTime / DateTimeOffset) before being added as DB parameters, preventing PostgreSQL from treating them as text.

Changes:

• Override BaseSqlQueryStructure.MakeDbConnectionParam to pre-parse PostgreSQL column parameters from string into the column’s inferred .NET system type before delegating to the base parameter creation logic.
• Minor GraphQL schema-generation refactors/cleanups (including primary key directive usage changes and DocumentNode composition changes).
• Improve/clarify several metadata-provider exception messages and update related comments/constants organization.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/Service.GraphQLBuilder/Sql/SchemaConverter.cs	Adjusts schema generation docs and changes how the primaryKey directive is emitted for PK fields.
src/Service.GraphQLBuilder/GraphQLTypes/SupportedTypes.cs	Reorganizes date/time-related type constants and updates comments.
src/Core/Services/MetadataProviders/SqlMetadataProvider.cs	Improves exception messages and clarifies a schema-fill comment.
src/Core/Services/GraphQLSchemaCreator.cs	Refactors schema assembly and uses WithDefinitions when composing root DocumentNode.
src/Core/Resolvers/Sql Query Structures/BaseSqlQueryStructure.cs	Adds PostgreSQL-specific parameter type pre-processing in MakeDbConnectionParam to address date/time filter casting issues.

[unattendedfaxmachine]

Adding context that this PR continues the work initially started in #3250 and #3101

[Aniruddh25]

If we need this implementation only for PostgreSQL explicitly, please override this function into a PostgreSqlQueryStructure. If such a class doesnt exist, please create it as a derived class inheriting from BaseSqlQueryStructure.

[Aniruddh25]

for non-string values, do we expect column system type to match the value type? If we cant be certain, shouldn't we do GetParamAsSystemType for kinds of values?

[Aniruddh25]

Suggested change

	throw new DataApiBuilderException(message: $"Source definition for entity '{entityName}' has not been inferred.",
	throw new DataApiBuilderException(message: $"Database object for entity '{entityName}' has not been inferred.",

[Aniruddh25]

by doing this arent we losing the key DB_OPERATION_RESULT_FIELD_NAME to value GetDbOperationResultField association?

[Aniruddh25]

This test should work now. Please keep it and make it functional

[Aniruddh25]

Good description on what is the change. Needs DateTime integration tests.