Fix the unsupported parameter type issue #157
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ **Issue 1: ABORT command not supported** - Move transaction command handling before SQL parsing - ABORT now works without 'sql parser error: Expected: an SQL statement, found: ABORT' - Early transaction detection prevents parser from rejecting ABORT ✅ **Issue 2: Nested transactions not implemented** - Handle nested BEGIN commands like PostgreSQL (ignore with warning) - TransactionStatus::Transaction + BEGIN -> Execution response (not error) - Matches PostgreSQL behavior of allowing nested transaction blocks These fixes address the main issues seen in integration tests: -⚠️ ABORT: sql parser error -> ✅ ABORT works -⚠️ Nested BEGIN: not implemented -> ✅ Nested BEGIN ignored (PostgreSQL standard) - More stable transaction state management Built against latest master with all recent updates included.
✅ **Issue 1: ABORT command not supported** - Handle transaction commands in BOTH simple and extended query paths - ABORT bypasses SQL parser completely in both protocols - Extended query parser creates dummy plan for transaction commands ✅ **Issue 2: Nested transactions not implemented** - Nested BEGIN returns success instead of error (PostgreSQL standard) - Warning logged but no failure - matches PostgreSQL behavior - Proper transaction state handling for all cases ✅ **Issue 3: Comprehensive transaction command coverage** - Fixed both SimpleQueryHandler and ExtendedQueryHandler paths - Transaction commands handled before SQL parsing in all cases - Supports all PostgreSQL transaction variants (ABORT, BEGIN WORK, etc.) This addresses all the failing test cases: -⚠️ ABORT: sql parser error -> ✅ ABORT works in all protocols -⚠️ Nested BEGIN: not implemented -> ✅ Nested BEGIN ignored with warning -⚠️ Extended query BEGIN issues -> ✅ Extended query transaction support Built and tested against latest master branch.
…d of FATAL errors ✅ **Issue: FATAL errors for unsupported parameter types** - Replace FATAL error with graceful degradation to TEXT type - Allow DBeaver and other clients to work with unsupported PostgreSQL parameter types - Prevents connection drops when clients use advanced parameter types - Matches the pattern we used for unknown parameter types in extended queries This fixes issues where clients like DBeaver would encounter: 'FATAL: Unsupported parameter type: <some_type>' Instead, unsupported types now gracefully fall back to TEXT, allowing the query to proceed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What I Fixed:
Replaced FATAL error with graceful degradation to TEXT type
Removed error message-based control flow (as you recommended earlier)
Prevents connection drops when DBeaver uses advanced parameter types