Fix the unsupported parameter type issue (#157)

* Fix high priority transaction issues (clean from updated master)

✅ **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.

* fmt

* Fix high priority transaction issues - comprehensive solution

✅ **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.

* Fix unsupported parameter type handling - graceful degradation instead 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.

Author: iPeluwa

arrow-pg/src/datatypes/df.rs

@@ -11,7 +11,7 @@ use futures::{stream, StreamExt};
 use pgwire::api::portal::{Format, Portal};
 use pgwire::api::results::QueryResponse;
 use pgwire::api::Type;
-use pgwire::error::{ErrorInfo, PgWireError, PgWireResult};
+use pgwire::error::{PgWireError, PgWireResult};
 use pgwire::messages::data::DataRow;
 use rust_decimal::prelude::ToPrimitive;
 use rust_decimal::Decimal;
@@ -262,11 +262,10 @@ where
             }
             // TODO: add more advanced types (composite types, ranges, etc.)
             _ => {
-                return Err(PgWireError::UserError(Box::new(ErrorInfo::new(
-                    "FATAL".to_string(),
-                    "XX000".to_string(),
-                    format!("Unsupported parameter type: {pg_type}"),
-                ))));
+                // Default to string/text for unsupported parameter types
+                // This allows graceful degradation instead of fatal errors
+                let value = portal.parameter::<String>(i, &pg_type)?;
+                deserialized_params.push(ScalarValue::Utf8(value));
             }
         }
     }