Repository: duckdb/duckdb (language: python)

Issue:
literal max uhugeint raises exception
### What happens?

The page https://duckdb.org/docs/sql/data_types/numeric
correctly states that the max value of a UHUGEINT should be
340282366920938463463374607431768211455

But the CLI gets confused:
```
D select 340282366920938463463374607431768211455::UHUGEINT;
Conversion Error:
Type DOUBLE with value 3.402823669209385e+38 can't be cast because the value is out of range for the destination type UINT128
```
Evidently it first attempts to parse the digit sequence before it gets to the type declaration.

The good news is DuckDB correctly handles 2^127 + (2^127 - 1):
 
select 170141183460469231731687303715884105728::UHUGEINT + 170141183460469231731687303715884105727;
```
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ (CAST(1.7014118346046923e+38 AS UHUGEINT) + 170141183460469231731687303715884105727) │
│                                       uint128                                        │
├──────────────────────────────────────────────────────────────────────────────────────┤
│                                              340282366920938463463374607431768211455 │
└──────────────────────────────────────────────────────────────────────────────────────┘
```

### To Reproduce

select 340282366920938463463374607431768211455::UHUGEINT;

### OS:

MacOC

### DuckDB Version:

1.1.4

### DuckDB Client:

CLI

### Hardware:

_No response_

### Full Name:

Peter Koppstein

### Affiliation:

Princeton University

### What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a source build

### Did you include all relevant data sets for reproducing the issue?

Not applicable - the reproduction does not require a data set

### Did you include all code required to reproduce the issue?

- [X] Yes, I have

### Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?

- [X] Yes, I have
literal max uhugeint raises exception
### What happens?

The page https://duckdb.org/docs/sql/data_types/numeric
correctly states that the max value of a UHUGEINT should be
340282366920938463463374607431768211455

But the CLI gets confused:
```
D select 340282366920938463463374607431768211455::UHUGEINT;
Conversion Error:
Type DOUBLE with value 3.402823669209385e+38 can't be cast because the value is out of range for the destination type UINT128
```
Evidently it first attempts to parse the digit sequence before it gets to the type declaration.

The good news is DuckDB correctly handles 2^127 + (2^127 - 1):
 
select 170141183460469231731687303715884105728::UHUGEINT + 170141183460469231731687303715884105727;
```
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ (CAST(1.7014118346046923e+38 AS UHUGEINT) + 170141183460469231731687303715884105727) │
│                                       uint128                                        │
├──────────────────────────────────────────────────────────────────────────────────────┤
│                                              340282366920938463463374607431768211455 │
└──────────────────────────────────────────────────────────────────────────────────────┘
```

### To Reproduce

select 340282366920938463463374607431768211455::UHUGEINT;

### OS:

MacOC

### DuckDB Version:

1.1.4

### DuckDB Client:

CLI

### Hardware:

_No response_

### Full Name:

Peter Koppstein

### Affiliation:

Princeton University

### What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a source build

### Did you include all relevant data sets for reproducing the issue?

Not applicable - the reproduction does not require a data set

### Did you include all code required to reproduce the issue?

- [X] Yes, I have

### Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?

- [X] Yes, I have


Discussion / hints:
Casting from string like `select '340282366920938463463374607431768211455'::UHUGEINT;` works around the issue, that I think is that literal -> double -> UHUGEINT is not information preserving. Thanks
Casting from string like `select '340282366920938463463374607431768211455'::UHUGEINT;` works around the issue, that I think is that literal -> double -> UHUGEINT is not information preserving. Thanks

Fix patch:
diff --git a/src/parser/transform/expression/transform_constant.cpp b/src/parser/transform/expression/transform_constant.cpp
index 3583256003e7..c8c76c19b837 100644
--- a/src/parser/transform/expression/transform_constant.cpp
+++ b/src/parser/transform/expression/transform_constant.cpp
@@ -55,6 +55,12 @@ unique_ptr<ConstantExpression> Transformer::TransformValue(duckdb_libpgquery::PG
 				// successfully cast to bigint: bigint value
 				return make_uniq<ConstantExpression>(Value::HUGEINT(hugeint_value));
 			}
+			uhugeint_t uhugeint_value;
+			// if that is not successful; try to cast as uhugeint
+			if (TryCast::Operation<string_t, uhugeint_t>(str_val, uhugeint_value)) {
+				// successfully cast to bigint: bigint value
+				return make_uniq<ConstantExpression>(Value::UHUGEINT(uhugeint_value));
+			}
 		}
 		idx_t decimal_offset = val.val.str[0] == '-' ? 3 : 2;
 		if (try_cast_as_decimal && decimal_position.IsValid() &&


Test patch:
diff --git a/test/sql/types/hugeint/test_hugeint_conversion.test b/test/sql/types/hugeint/test_hugeint_conversion.test
index f78f5825fa2a..275cf128eee9 100644
--- a/test/sql/types/hugeint/test_hugeint_conversion.test
+++ b/test/sql/types/hugeint/test_hugeint_conversion.test
@@ -166,7 +166,7 @@ SELECT 1e100::DOUBLE::HUGEINT;
 query TTTTT
 SELECT typeof(10), typeof(10000000000), typeof(170141183460469231731687303715884105727), typeof(170141183460469231731687303715884105728), typeof(170141183460469231731687303715884105728000)
 ----
-INTEGER	BIGINT	HUGEINT	DOUBLE	DOUBLE
+INTEGER	BIGINT	HUGEINT	UHUGEINT	DOUBLE
 
 # exponents are always double
 query III
diff --git a/test/sql/types/uhugeint/test_uhugeint_conversion.test b/test/sql/types/uhugeint/test_uhugeint_conversion.test
index 664293ac01c5..7b64365099cd 100644
--- a/test/sql/types/uhugeint/test_uhugeint_conversion.test
+++ b/test/sql/types/uhugeint/test_uhugeint_conversion.test
@@ -155,7 +155,7 @@ Conversion Error
 query TTTTT
 SELECT typeof(10), typeof(10000000000), typeof(170141183460469231731687303715884105727), typeof(170141183460469231731687303715884105728), typeof(170141183460469231731687303715884105728000)
 ----
-INTEGER	BIGINT	HUGEINT	DOUBLE	DOUBLE
+INTEGER	BIGINT	HUGEINT	UHUGEINT	DOUBLE
 
 # exponents are always double
 query III
diff --git a/test/sql/types/uhugeint/uhugeint_literal.test b/test/sql/types/uhugeint/uhugeint_literal.test
new file mode 100644
index 000000000000..d8738a07b5f1
--- /dev/null
+++ b/test/sql/types/uhugeint/uhugeint_literal.test
@@ -0,0 +1,23 @@
+# name: test/sql/types/uhugeint/uhugeint_literal.test
+# description: Test uhugeint literals
+# group: [uhugeint]
+
+query I
+select 340282366920938463463374607431768211455
+----
+340282366920938463463374607431768211455
+
+query I
+select typeof(340282366920938463463374607431768211455)
+----
+UHUGEINT
+
+query I
+select 340282366920938463463374607431768211456
+----
+340282366920938463463374607431768211456
+
+query I
+select typeof(340282366920938463463374607431768211456)
+----
+DOUBLE