Reviewing files that changed from the base of the PR and between 411d10d and 8ffc441.

• cypher/models/cypher/model.go (6 hunks)
• cypher/models/pgsql/test/testcase.go (3 hunks)
• cypher/models/pgsql/translate/constraints.go (1 hunks)
• cypher/models/pgsql/translate/expression.go (1 hunks)
• cypher/models/pgsql/translate/function.go (1 hunks)
• cypher/models/pgsql/translate/model.go (2 hunks)
• cypher/models/walk/walk.go (4 hunks)
• cypher/models/walk/walk_test.go (1 hunks)
• drivers/neo4j/result_internal_test.go (1 hunks)
• drivers/neo4j/v2/database.go (2 hunks)
• drivers/neo4j/v2/driver.go (3 hunks)
• drivers/neo4j/v2/schema.go (1 hunks)
• drivers/pg/query/sql/schema_up.sql (1 hunks)
• drivers/pg/v2/database.go (1 hunks)
• drivers/pg/v2/driver.go (1 hunks)
• drivers/pg/v2/manager.go (1 hunks)
• drivers/pg/v2/mapper.go (1 hunks)
• drivers/pg/v2/model/format.go (1 hunks)
• drivers/pg/v2/model/model.go (1 hunks)
• drivers/pg/v2/pg.go (1 hunks)
• drivers/pg/v2/query/definitions.go (1 hunks)
• drivers/pg/v2/query/format.go (1 hunks)
• drivers/pg/v2/query/query.go (1 hunks)
• drivers/pg/v2/query/sql.go (1 hunks)
• drivers/pg/v2/query/sql/insert_graph.sql (1 hunks)
• drivers/pg/v2/query/sql/insert_or_get_kind.sql (1 hunks)
• drivers/pg/v2/query/sql/schema_down.sql (1 hunks)
• drivers/pg/v2/query/sql/schema_up.sql (1 hunks)
• drivers/pg/v2/query/sql/select_graph_by_name.sql (1 hunks)
• drivers/pg/v2/query/sql/select_graphs.sql (1 hunks)
• drivers/pg/v2/query/sql/select_kind_id.sql (1 hunks)
• drivers/pg/v2/query/sql/select_kinds.sql (1 hunks)
• drivers/pg/v2/query/sql/select_table_indexes.sql (1 hunks)
• drivers/pg/v2/statements.go (1 hunks)
• drivers/pg/v2/types.go (1 hunks)
• drivers/pg/v2/util.go (1 hunks)
• graph/mapper.go (2 hunks)
• graph/properties.go (1 hunks)
• graph/query.go (1 hunks)
• ops/ops.go (2 hunks)
• query/builder.go (2 hunks)
• query/neo4j/neo4j.go (3 hunks)
• v2/driver.go (2 hunks)
• v2/ops.go (1 hunks)
• v2/query.go (7 hunks)
• v2/query_test.go (2 hunks)
• v2/registry.go (1 hunks)
• v2/registry_integration_test.go (2 hunks)
• v2/schema.go (1 hunks)
• v2/util.go (1 hunks)

drivers/pg/v2/query/sql/select_kinds.sql (1)

1-3: Consider adding a deterministic ordering clause

Without an ORDER BY, consecutive calls can return rows in different orders depending on the planner.
If client-side tests or caches rely on a stable order, append an explicit sort (e.g. ORDER BY name).
[ suggest_optional_refactor ]

-select id, name
-from kind;
+select id, name
+from kind
+order by name;

cypher/models/pgsql/translate/function.go (1)

16-16: Signature updated – confirm all visitors use the new interface

walk.NewSimpleVisitor now receives a walk.VisitorHandler.
The change is correct but breaks callers still passing walk.CancelableErrorHandler. Make sure:

1. All custom visitors in the repo import the new interface.
2. Down-stream libraries/modules depending on this package are updated before release.

#!/bin/bash
# Find any remaining references to the old interface
rg --no-heading --line-number "CancelableErrorHandler"

drivers/pg/v2/query/sql/select_kind_id.sql (1)

1-4: LGTM! Clean and secure SQL query.

The query correctly uses parameter binding (@name) to prevent SQL injection and has a clear, focused purpose.

graph/query.go (1)

26-26: LGTM! Consistent with the mapper interface refactoring.

The method name change from TryMap to Map aligns with the broader refactoring of the ValueMapper interface mentioned in the AI summary.

drivers/pg/v2/query/sql/insert_graph.sql (1)

1-4: LGTM! Efficient and secure SQL implementation.

The INSERT statement correctly uses parameter binding (@name) and efficiently returns the new ID with the RETURNING clause, avoiding the need for a separate SELECT query.

drivers/pg/query/sql/schema_up.sql (1)

535-535: LGTM! Helpful debug logging for graph traversal monitoring.

The debug statement provides valuable runtime insights during path expansion operations, including the current step, available paths, and satisfied paths count. This will aid in troubleshooting and performance analysis of the graph traversal harness.

drivers/pg/v2/query/sql/select_table_indexes.sql (1)

1-6: LGTM! Clean and focused index introspection query.

The SQL query properly filters by schema and uses parameterized table name for safe index definition retrieval. This supports the schema management framework for comparing existing vs. required indexes.

cypher/models/walk/walk_test.go (1)

15-15: LGTM! Interface type updated to align with visitor pattern refactoring.

The parameter type change from CancelableErrorHandler to VisitorHandler correctly reflects the interface refactoring in cypher/models/walk/walk.go where the interface was renamed and expanded with additional methods like Consume() and WasConsumed().

drivers/neo4j/result_internal_test.go (1)

18-18: LGTM! Method call updated to reflect mapper interface refactoring.

The change from TryMap to Map correctly aligns with the method rename in the ValueMapper interface as mentioned in the AI summary. The test logic and assertions remain unchanged.

cypher/models/pgsql/test/testcase.go (1)

103-103: LGTM! Consistent interface type updates across test methods.

The parameter type changes from CancelableErrorHandler to VisitorHandler in the WriteTo, Assert, and AssertLive methods correctly align with the visitor pattern refactoring in cypher/models/walk/walk.go. All three methods are consistently updated to use the new VisitorHandler interface.

Also applies to: 155-155, 186-186

cypher/models/pgsql/translate/constraints.go (1)

179-179: Interface refactoring looks good.

The update from walk.CancelableErrorHandler to walk.VisitorHandler aligns with the broader visitor pattern standardization across the codebase. The function logic remains unchanged, and the new interface provides additional consumption tracking capabilities.

ops/ops.go (1)

53-53: Method renaming looks correct.

The update from mapper.TryMap to mapper.Map aligns with the ValueMapper interface refactoring. The method calls maintain the same boolean return pattern and error handling logic.

Also applies to: 196-196, 199-199, 202-202

drivers/pg/v2/query/sql/insert_or_get_kind.sql (1)

1-12: Well-structured upsert implementation.

The SQL correctly implements an upsert pattern using CTE and UNION to handle both existing and new kind records. The use of ON CONFLICT (name) DO NOTHING prevents duplicate key violations while ensuring a single ID is always returned.

cypher/models/pgsql/translate/expression.go (1)

116-116: Consistent interface update.

The change from walk.CancelableErrorHandler to walk.VisitorHandler is consistent with the visitor pattern refactoring across the codebase. The function continues to extract syntax node references correctly with the enhanced interface.

v2/ops.go (1)

9-13: Architectural improvement with separated query preparation.

The refactoring from *cypher.RegularQuery to *PreparedQuery and the corresponding driver method change from Execute to CypherQuery represents a cleaner separation of concerns. The new approach explicitly handles query parameters through the PreparedQuery structure, improving type safety and making parameter management more transparent.

v2/registry_integration_test.go (3)

34-45: Verify schema assertion integrates properly with the driver.

The schema assertion defines node/edge kinds and a text search index. The implementation looks correct for demonstrating the new schema management capabilities.

---

47-48: Good separation of query building and execution.

The pattern of building a prepared query first, then using it in sessions/transactions is a good architectural choice that separates concerns.

---

50-54: Verify CreateNode method handles node properties correctly.

The node creation uses graph.PrepareNode with properties and kinds. Ensure the implementation properly validates and persists the node data.

#!/bin/bash
# Description: Verify CreateNode method implementation and error handling

# Search for CreateNode method implementations
ast-grep --pattern $'func ($$$) CreateNode($_, $_) $_ {
  $$$
}'

# Look for error handling in CreateNode calls
rg -A 10 "CreateNode.*error"

graph/mapper.go (2)

368-376: Method rename from TryMap to Map is a breaking change.

This rename appears intentional and aligns with similar changes across the codebase. The implementation remains unchanged which is good for consistency.

---

378-390: MapAll implementation is correct and follows good practices.

The method properly validates input lengths and fails fast on any mapping error. The sequential processing approach is appropriate for the use case.

v2/query_test.go (3)

15-36: Simplified query string generation improves readability.

The direct use of format.RegularQuery instead of buffer/emitter makes the test more concise and easier to understand.

---

37-46: CREATE node test case validates parameterized properties correctly.

The test correctly validates that a node creation with kinds and parameters generates the expected Cypher syntax create (n:A $props).

---

48-59: CREATE relationship test demonstrates complex pattern building.

The test shows creating a relationship from a node identified by ID with parameterized properties. The expected Cypher match (s), (e) where id(s) = 1234 create (s)-[r:A $props]->(e) looks correct.

query/neo4j/neo4j.go (3)

112-132: Visitor interface update aligns with codebase refactoring.

The change from CancelableErrorHandler to VisitorHandler is consistent with the broader visitor pattern updates across the codebase.

---

145-167: Simplified variable symbol access improves code clarity.

The direct access to typedElement.Variable.Symbol without type assertion suggests improved type safety in the underlying model. This simplification makes the code cleaner.

---

263-269: Error compilation visitor update is consistent.

The visitor interface update maintains the same error collection logic while using the new VisitorHandler interface.

query/builder.go (2)

67-87: Visitor interface update maintains consistency across query builders.

The change to VisitorHandler is consistent with the same updates in query/neo4j/neo4j.go, ensuring uniform visitor pattern usage across the codebase.

---

100-122: Variable symbol access simplification improves maintainability.

The direct access to typedNode.Variable.Symbol without type assertions matches the pattern used in the Neo4j query builder, providing consistency across implementations.

cypher/models/pgsql/translate/model.go (1)

543-543: Variable declaration is more explicit and clear.

The explicit declaration of variableExpression as *cypher.Variable improves code readability. The function logic remains sound with proper nil checking before accessing the Symbol field.

Note: The AI summary incorrectly states that the type switch and error handling were removed, but they are still present in the code.

Also applies to: 569-569

Likely an incorrect or invalid review comment.

drivers/neo4j/v2/database.go (3)

20-20: Schema manager integration follows good patterns.

The addition of the schemaManager field and its initialization in the constructor properly integrates schema management capabilities into the database abstraction.

Also applies to: 29-29

---

33-35: Method delegation is clean and appropriate.

The AssertSchema method correctly delegates to the schema manager, maintaining separation of concerns.

---

51-51: Constant name update aligns with interface changes.

The change from v2.SessionOptionReadOnly to v2.OptionReadOnly is consistent with the v2 package interface updates.

drivers/pg/v2/query/definitions.go (3)

7-7: Column index regex pattern looks more robust.

The column index regex (?i)^create\s+(unique)?(?:\s+)?index\s+([^ ]+)\s+on\s+\S+\s+using\s+([^ ]+)\s+\(([^)]+)\)$ appears more straightforward and less prone to ReDoS vulnerabilities than the property index pattern.

---

10-21: Constants correctly map to regex capture groups.

The constants properly define the expected regex group indices and values, making the code maintainable and reducing magic numbers.

---

6-6: Review regex pattern for potential ReDoS vulnerabilities.

The property index regex pattern is complex with multiple optional groups and could be vulnerable to ReDoS attacks. The pattern (?i)^create\s+(unique)?(?:\s+)?index\s+([^ ]+)\s+on\s+\S+\s+using\s+([^ ]+)\s+\(+properties\s+->>\s+'([^:]+)::.+$ contains potentially problematic constructs.

#!/bin/bash
# Test the regex patterns for potential ReDoS vulnerabilities by checking against malicious inputs
# This will help identify if the regex can cause catastrophic backtracking

echo "Testing PostgreSQL index regex patterns for ReDoS vulnerabilities..."

# Create a test file to analyze the regex patterns
cat > test_regex.go << 'EOF'
package main

import (
	"fmt"
	"regexp"
	"time"
)

func testRegex(pattern string, input string, description string) {
	re := regexp.MustCompile(pattern)
	start := time.Now()
	
	// Test with timeout to catch ReDoS
	done := make(chan bool, 1)
	go func() {
		_ = re.MatchString(input)
		done <- true
	}()
	
	select {
	case <-done:
		duration := time.Since(start)
		fmt.Printf("%s: Completed in %v\n", description, duration)
	case <-time.After(5 * time.Second):
		fmt.Printf("%s: TIMEOUT - Potential ReDoS vulnerability\n", description)
	}
}

func main() {
	// Test patterns from the file
	pgPropertyIndexRegex := `(?i)^create\s+(unique)?(?:\s+)?index\s+([^ ]+)\s+on\s+\S+\s+using\s+([^ ]+)\s+\(+properties\s+->>\s+'([^:]+)::.+$`
	pgColumnIndexRegex := `(?i)^create\s+(unique)?(?:\s+)?index\s+([^ ]+)\s+on\s+\S+\s+using\s+([^ ]+)\s+\(([^)]+)\)$`
	
	// Malicious inputs that could cause ReDoS
	maliciousInput1 := "create    " + strings.Repeat(" ", 1000) + "index"
	maliciousInput2 := "create unique" + strings.Repeat("  ", 1000) + "index"
	
	testRegex(pgPropertyIndexRegex, maliciousInput1, "Property index regex with excessive spaces")
	testRegex(pgColumnIndexRegex, maliciousInput2, "Column index regex with excessive spaces")
}
EOF

# Check if we can compile and run the test (but don't actually run it to avoid security issues)
go mod init test-regex 2>/dev/null || true
echo "Created test file to analyze regex patterns."
echo "The regex patterns should be reviewed for catastrophic backtracking vulnerabilities."

drivers/pg/v2/statements.go (2)

4-7: Node creation statements look correct.

The SQL statements for node creation properly use parameterized queries and PostgreSQL-specific syntax like unnest for batch operations. The return of composite types is well-structured.

---

18-21: Property update statements use secure JSONB operations.

The edge property update statements correctly use PostgreSQL's JSONB operators (|| for merge, - for deletion) and parameterized queries to prevent SQL injection.

drivers/pg/v2/query/sql/schema_down.sql (3)

1-29: Comprehensive function and trigger cleanup.

The script systematically drops all graph-related functions and triggers in a logical order. The cleanup is thorough and covers all the components needed for the graph database functionality.

---

30-35: Table dropping follows proper dependency order.

The tables are dropped in the correct dependency order (node, edge, kind, graph) to avoid foreign key constraint violations.

---

37-71: Good error handling for custom types.

The use of DO blocks with exception handling ensures the script doesn't fail if custom types don't exist, making it safe to run multiple times.

drivers/pg/v2/model/model.go (3)

18-25: Efficient constructor pattern with proper initialization.

Good use of map initialization with empty maps for the "add" fields while leaving slice fields as nil, which is appropriate for their usage pattern.

---

41-46: Efficient memory allocation using make with capacity.

Good practice using make() with explicit capacity based on slice length to avoid map reallocations during population.

---

48-54: Missing import for IndexName and ConstraintName functions.

The code calls IndexName and ConstraintName functions, but these aren't imported or defined in this file. This will cause compilation errors.

Add the missing function calls by importing from the same package:

 	for _, index := range indexes {
-		graphPartition.Indexes[IndexName(name, index)] = index
+		graphPartition.Indexes[IndexName(name, index)] = index
 	}
 
 	for _, constraint := range constraints {
-		graphPartition.Constraints[ConstraintName(name, constraint)] = constraint
+		graphPartition.Constraints[ConstraintName(name, constraint)] = constraint
 	}

Since these functions are in the same package (model), they should be accessible without additional imports. Verify that the functions are properly defined in the package.

Likely an incorrect or invalid review comment.

drivers/pg/v2/pg.go (3)

40-51: Efficient connection lifecycle management with proper logging.

The connection release hook correctly identifies and destroys connections missing composite types. The warning log provides good visibility into connection pool health.

---

26-38: Robust composite type registration with error handling.

Good error handling that distinguishes between "object does not exist" errors and other failures. The type registration is essential for proper PostgreSQL composite type support.

---

88-102: Verify driver registration pattern for potential conflicts.

The driver registration follows Go conventions but should verify that the driver name "pg_v2" doesn't conflict with existing drivers.

#!/bin/bash
# Description: Check for potential driver name conflicts in the codebase
# Expected: No other drivers using "pg_v2" name

# Search for other driver registrations
rg -A 3 -B 3 'Register.*"pg.*"'

# Search for references to pg_v2 driver name
rg '"pg_v2"'

drivers/pg/v2/database.go (2)

13-28: Clean transaction option handling with proper defaults.

The beginTx function correctly defaults to read-write mode and properly handles the read-only option. The transaction options setup is well-structured.

---

48-55: Proper resource management in Session method.

The connection acquisition and release pattern with defer is correctly implemented. The error handling ensures connections are released even when acquisition succeeds but driver logic fails.

drivers/pg/v2/query/sql.go (3)

15-31: Efficient SQL comment stripping with clean implementation.

The comment stripping logic correctly handles empty lines and SQL comments while preserving the essential SQL content. Using strings.Builder for concatenation is efficient.

---

33-39: Appropriate use of panic for build-time errors.

Using panic() for missing embedded files is correct since this represents a build-time configuration error that should be caught during development.

---

10-13: Proper embed directive usage for SQL file management.

The //go:embed sql directive is correctly used to embed the SQL directory, enabling self-contained binary deployment.

v2/schema.go (2)

34-47: Well-structured schema types

The Graph and Schema structs are well-designed with appropriate encapsulation. The unexported defaultGraph field ensures controlled access through the DefaultGraph() method.

---

49-65: Idiomatic Go constructor and accessor methods

The NewSchema constructor and DefaultGraph() method follow Go best practices, including the comma-ok idiom for map lookups.

drivers/neo4j/v2/driver.go (2)

36-38: Correct migration to new mapper interface

The update from TryMap to Map is correctly implemented with appropriate error handling.

Also applies to: 113-115

---

161-194: Well-implemented driver methods

The new methods CreateNode, Raw, and CypherQuery are correctly implemented with proper error handling and delegation patterns.

v2/driver.go (3)

14-16: Improved option naming

The renamed constants OptionReadOnly and OptionReadWrite are more descriptive than the previous names.

---

23-36: Well-designed interface updates

The updated Driver and Database interfaces provide better separation of concerns with dedicated methods for graph operations and schema management.

---

45-69: Correct error result implementation

The errorResult type correctly implements the Result interface for error cases, providing a clean error handling pattern.

cypher/models/cypher/model.go (2)

162-162: Improved type safety with specific pointer types

The refinement from generic Expression to specific *Variable pointers improves type safety and makes the API clearer. The RemoveItem.Property change to Expression appropriately increases flexibility.

Also applies to: 267-267, 295-295, 426-426, 568-568

---

169-174: Useful constructor addition

The NewProjectionItemWithExpr constructor provides a convenient way to create projection items with expressions.

drivers/pg/v2/mapper.go (2)

49-102: Well-structured mapping function

The newMapFunc implementation correctly handles all target types with proper type assertions and error handling.

---

104-106: Clean factory function

The newValueMapper constructor properly encapsulates the mapping logic for use with the graph package.

cypher/models/walk/walk.go (1)

11-19: Well-designed consumption tracking mechanism.

The addition of Consume() and WasConsumed() methods provides a clean way to control syntax tree traversal, allowing visitors to stop processing of subtrees when needed. The implementation correctly resets the consumption state after checking.

Also applies to: 58-67, 188-188

drivers/pg/v2/manager.go (1)

37-56: Excellent thread-safe design with efficient caching.

The SchemaManager implements a well-designed concurrent access pattern with RWMutex, proper lock escalation from read to write locks when cache misses occur, and efficient caching of kinds and graphs. The public getter methods correctly protect read access.

Also applies to: 98-102, 272-277

drivers/pg/v2/driver.go (2)

16-76: Well-implemented result handling with proper value mapping.

The queryResult implementation correctly handles iteration, scanning with type safety through the ValueMapper, and error propagation. The takeFirst optimization for single results is a nice touch.

---

165-182: Clean node creation with proper schema assertion.

The CreateNode method correctly asserts the graph and kinds before creating the node, ensuring schema consistency. The JSONB conversion for properties is handled appropriately.

drivers/pg/v2/types.go (1)

12-18: Well-designed composite types for graph entities.

The composite structs provide clean abstractions for nodes, edges, and paths with proper conversion methods to domain types. The TryMap pattern for optional mapping is elegant.

Also applies to: 125-166, 168-207, 209-292

drivers/neo4j/v2/schema.go (2)

284-333: Excellent schema synchronization implementation.

The AssertSchema method properly compares the required schema with the present schema, handling additions, removals, and type changes for both indexes and constraints. The separation of index and constraint operations into different transactions is appropriate for Neo4j.

---

222-282: Robust schema fetching with proper Neo4j 4.4+ handling.

The fetchPresentSchema method correctly handles the Neo4j 4.4+ default index edge case and validates against composite indexes. The value mapping using the Neo4j mapper is clean and type-safe.

v2/util.go (6)

27-39: LGTM!

The function correctly validates that node and relationship patterns aren't mixed and conditionally adds a node pattern.

---

41-85: Well-structured relationship pattern preparation.

The function correctly handles the mutual exclusivity of creation and constraint operations on relationships, and properly constructs pattern elements based on the identifier states.

---

87-108: LGTM!

The variable extraction correctly handles all relevant Cypher expression types.

---

110-133: LGTM!

Clean implementation of a string set with union operation.

---

165-223: LGTM!

The visitor correctly tracks clause context and categorizes identifiers appropriately. The default behavior of treating identifiers in non-updating clauses as constrained is sensible.

---

225-232: LGTM!

Clean wrapper function with proper error propagation.

drivers/pg/v2/query/format.go (6)

44-46: Implementation is correct for PostgreSQL.

In PostgreSQL, unique constraints are implemented as unique indexes, so using DROP INDEX to remove constraints is the correct approach.

---

195-205: LGTM!

The validation functions properly accumulate updates and propagate errors.

Also applies to: 290-300

---

236-288: LGTM!

The relationship batch update correctly manages both node and relationship updates with proper validation.

---

207-215: Consider thread safety for Future type.

If Future values are accessed concurrently, consider adding synchronization or documenting that they should only be accessed from a single goroutine.

#!/bin/bash
# Check if Future is used in concurrent contexts
rg -B 3 -A 3 "Future\[" --type go | grep -E "(go |goroutine|concurrent|parallel)"

---

84-104: Ensure property names are validated.

The function concatenates property names directly into SQL. Verify that propertyNames are validated or sanitized before use.

#!/bin/bash
# Search for usage of formatConflictMatcher to check property name sources
rg -B 5 -A 2 "formatConflictMatcher" --type go

---

48-68: Validate inputs to prevent SQL injection.

While the current usage appears safe, ensure that constraintName, tableName, and fieldName are validated or come from trusted sources to prevent SQL injection.

#!/bin/bash
# Search for callers of these format functions to verify input sources
rg -A 5 "formatCreateProperty(Index|Constraint)" --type go

v2/query.go (3)

517-534: LGTM!

The parameter extraction correctly handles duplicates and clears values from the AST.

---

208-272: LGTM!

Clean implementation of the entity builder with good use of generics for type safety.

---

156-190: LGTM!

The comparison continuation correctly generates comparison expressions for all supported operators.

drivers/pg/v2/query/sql/schema_up.sql (3)

56-74: Well-designed schema with appropriate partitioning.

The table structure correctly uses partitioning for scalability and includes appropriate constraints to maintain data integrity.

Also applies to: 93-102, 134-147

---

111-114: LGTM! Comprehensive index coverage.

The indexes cover all common query patterns including array containment queries with GIN indexes.

Also applies to: 180-189

---

152-171: Appropriate use of triggers for cascading deletes.

The trigger-based approach correctly handles cascading deletes across partitions where foreign keys would be impractical.

drivers/pg/v2/query/query.go (4)

26-41: LGTM!

The query execution helpers correctly handle both positional and named arguments using pgx's NamedArgs feature.

---

374-457: Excellent schema assertion implementation.

The method correctly computes the minimal changeset by comparing required and present indexes/constraints, and properly handles type changes by removing and re-adding indexes.

---

121-147: LGTM! Proper error handling.

The method correctly distinguishes between actual errors and no rows found, returning the appropriate pgx.ErrNoRows.

---

43-76: Consider the fragility of regex-based parsing.

While the regex approach works, it's fragile to PostgreSQL version changes. Consider adding version checks or more robust parsing if this becomes an issue.

#!/bin/bash
# Check regex definitions to understand the expected formats
rg "pgPropertyIndexRegex|pgColumnIndexRegex" --type go

Reviewing files that changed from the base of the PR and between 8ffc441 and f85e0d1.

• cypher/models/walk/walk.go (4 hunks)
• drivers/neo4j/v2/driver.go (3 hunks)
• drivers/neo4j/v2/schema.go (1 hunks)
• drivers/pg/v2/manager.go (1 hunks)
• drivers/pg/v2/mapper.go (1 hunks)
• drivers/pg/v2/query/sql.go (1 hunks)
• drivers/pg/v2/query/sql/select_graph_by_name.sql (1 hunks)
• drivers/pg/v2/query/sql/select_graphs.sql (1 hunks)
• drivers/pg/v2/types.go (1 hunks)
• v2/query.go (7 hunks)
• v2/registry.go (1 hunks)
• v2/schema.go (1 hunks)

• v2/registry.go
• drivers/pg/v2/query/sql/select_graphs.sql
• drivers/pg/v2/query/sql/select_graph_by_name.sql
• drivers/pg/v2/query/sql.go
• v2/schema.go
• drivers/pg/v2/mapper.go
• cypher/models/walk/walk.go

drivers/neo4j/v2/driver.go (4)

36-36: LGTM: Consistent mapper API migration

The change from mapper.TryMap to mapper.Map is consistent with the broader v2 API refactoring mentioned in the summary. The boolean return logic remains the same.

Also applies to: 113-113

---

156-159: LGTM: Clear no-op implementation

The WithGraph method is clearly documented as a no-op, which aligns with the interface requirements.

---

161-181: LGTM: Well-structured CreateNode implementation

The method properly constructs a Cypher CREATE query using the v2 query builder, handles errors appropriately, and ensures proper resource cleanup by closing the result and checking for errors.

---

188-194: LGTM: Clean delegation pattern

The refactored CypherQuery method properly formats the query, uses v2.NewErrorResult for error handling, and delegates execution to the Raw method following a clean separation of concerns.

drivers/neo4j/v2/schema.go (2)

136-142: LGTM: Appropriate transaction rollback handling

Based on my understanding of Neo4j Go driver v5, the current deferred rollback pattern is correct. The driver handles rollback-after-commit scenarios gracefully, and the debug logging approach acknowledges the difficulty of detecting specific error types in this version.

---

286-335: LGTM: Comprehensive schema assertion logic

The AssertSchema method implements a thorough comparison between required and present schemas, correctly identifying indexes and constraints to add or remove. The logic properly handles type mismatches by removing and re-adding elements, and the order of operations (constraints before indexes) is appropriate for Neo4j.

v2/query.go (6)

8-9: LGTM! Clean import organization.

The import structure is well-organized with the new cypher models import properly placed.

---

129-154: LGTM! Well-designed interface hierarchy.

The interface definitions create a clean hierarchy with proper separation of concerns:

• EntityContinuation provides core entity operations
• Comparable defines comparison operations
• PropertyContinuation and IdentityContinuation extend functionality appropriately

The fluent interface pattern is well-implemented.

---

156-206: LGTM! Solid continuation implementation.

The comparisonContinuation and propertyContinuation types provide a clean foundation for the fluent interface pattern:

• Consistent method signatures across comparison operations
• Proper delegation to shared asComparison method
• Clean separation between property operations (Set/Remove) and comparisons

---

208-272: LGTM! Effective use of Go generics.

The generic entity[T] type provides excellent code reuse while maintaining type safety:

• Pattern methods properly construct Cypher AST nodes
• ID() and Property() methods return appropriate continuation types
• Consistent error handling and validation throughout

---

299-344: LGTM! Clean query builder interface extension.

The addition of the Create method and PreparedQuery return type enhances the builder pattern:

• Consistent method signature with other builder methods
• Proper slice append pattern in implementation
• Maintains fluent interface chainability

---

517-534: LGTM! Clean parameter extraction implementation.

The stripASTParameters function effectively uses the visitor pattern to extract and clear parameter values from the AST:

• Proper duplicate parameter detection
• Clean separation of concerns with visitor pattern
• Appropriate error handling with SetErrorf