sqlString improvements

[jycor]

No description provided.

[github-actions]

	Main	PR
covering_index_scan_postgres	1949.67/s	1926.06/s	-1.3%
groupby_scan_postgres	132.80/s	134.15/s	+1.0%
index_join_postgres	688.10/s	684.48/s	-0.6%
index_join_scan_postgres	865.27/s	854.87/s	-1.3%
index_scan_postgres	24.81/s	25.56/s	+3.0%
oltp_delete_insert_postgres	829.12/s	848.02/s	+2.2%
oltp_insert	735.27/s	726.14/s	-1.3%
oltp_point_select	3088.39/s	3096.26/s	+0.2%
oltp_read_only	3093.77/s	3062.79/s	-1.1%
oltp_read_write	2341.82/s	2351.48/s	+0.4%
oltp_update_index	756.56/s	746.34/s	-1.4%
oltp_update_non_index	794.94/s	790.92/s	-0.6%
oltp_write_only	1767.88/s	1819.97/s	+2.9%
select_random_points	1974.41/s	1966.82/s	-0.4%
select_random_ranges	1154.35/s	1146.23/s	-0.8%
table_scan_postgres	23.70/s	24.69/s	+4.1%
types_delete_insert_postgres	809.83/s	787.58/s	-2.8%
types_table_scan_postgres	10.40/s	10.73/s	+3.1%

[itoqa]

Ito Test Report ✅

7 test cases ran. 1 additional finding, 6 passed.

The unified run passed 6 of 7 TIME-related tests, confirming stable behavior for canonical formatting (including trailing-zero trimming), consistency between pgwire and ::text output paths, exact preservation of 24:00:00, default six-digit fractional precision when typmod is unspecified, and parse-stable high-fanout validation across 14,336 rows with no malformed values.
The only failure was a medium-severity, pre-existing implementation gap where TIME(n) casts do not reliably enforce typmod rounding for TIME(0)/TIME(3), likely due to unimplemented timetypmodin/timetypmodout functions, so precision-sensitive workflows should currently normalize TIME values in application logic.

✅ Passed (6)

Category	Summary	Screenshot
Format	Canonical TIME text matches expected values for zero, trimmed, and max fractional cases.
Format	TIME output trims trailing fractional zeros correctly (12:34:56.120000 -> 12:34:56.12).
Format	Wire TIME output and ::text formatting stay consistent across representative values.
Precision	Casting 24:00:00 as TIME preserved the 24-hour boundary and returned 24:00:00 exactly.
Precision	Casting TIME without explicit typmod preserved six-digit fractional precision (10:11:12.123456).
Safety	High-fanout TIME output remained canonical and parse-stable across 14,336 rows in local non-production validation.

ℹ️ Additional Findings (1)

These findings are unrelated to the current changes but were observed during testing.

Category	Summary	Screenshot
Precision	🟠 TIME typmod precision casts are not fully enforced, so expected rounding behavior for TIME(0) / TIME(3) is unreliable.

🟠 TIME typmod precision casts do not enforce rounding

• What failed: Typmod-specific rounding expectations for TIME(0) and TIME(3) were not reliably applied, indicating precision modifiers are not being enforced end-to-end for TIME casts.
• Impact: Workflows that depend on strict TIME(n) precision can return values at unexpected precision, causing inconsistent behavior in validation, round-tripping, and downstream comparisons. A workaround is to avoid relying on typmod rounding and normalize values in application logic.
• Steps to reproduce:
  1. Run casts for boundary literals (for example 12:34:56.999999, 12:34:56.100000, 12:34:56.000001) using TIME(0), TIME(3), and TIME(6).
  2. Read values back as text and re-cast to TIME in the same session.
  3. Compare observed values against expected typmod-rounded outcomes.
• Stub / mock context: Local authentication and domain-constraint checks were temporarily bypassed so SQL sessions could run deterministically in this environment; TIME parsing, typmod handling, and formatting paths were exercised against application code without per-test response stubs.
• Code analysis: I inspected TIME input/output and typmod wiring in the production code. time_in only rounds when a usable typmod is provided, but timetypmodin and timetypmodout are still TODO stubs that return nil, so precision metadata for TIME is not fully implemented in the function layer.
• Why this is likely a bug: The production TIME typmod IO functions required to parse and emit precision modifiers are explicitly unimplemented, which directly explains why typmod-driven rounding behavior is unreliable at runtime.

Relevant code:

server/functions/time.go (lines 49-54)

typmod := val3.(int32)
if typmod == -1 {
    typmod = 6
}
precision := tree.TimeFamilyPrecisionToRoundDuration(typmod)
if strings.EqualFold(input, "now") {

server/functions/time.go (lines 111-120)

// timetypmodin represents the PostgreSQL function of time type IO typmod input.
var timetypmodin = framework.Function1{
    Name:       "timetypmodin",
    Return:     pgtypes.Int32,
    Parameters: [1]*pgtypes.DoltgresType{pgtypes.CstringArray},
    Strict:     true,
    Callable: func(ctx *sql.Context, _ [2]*pgtypes.DoltgresType, val any) (any, error) {
        // TODO: typmod=(precision<<16)∣scale
        return nil, nil
    },
}

server/functions/time.go (lines 123-134)

// timetypmodout represents the PostgreSQL function of time type IO typmod output.
var timetypmodout = framework.Function1{
    Name:       "timetypmodout",
    Return:     pgtypes.Cstring,
    Parameters: [1]*pgtypes.DoltgresType{pgtypes.Int32},
    Strict:     true,
    Callable: func(ctx *sql.Context, _ [2]*pgtypes.DoltgresType, val any) (any, error) {
        // TODO
        // Precision = typmod & 0xFFFF
        // Scale = (typmod >> 16) & 0xFFFF
        return nil, nil
    },
}

Commit: 9556c8f

View Full Run

---

Tell us how we did: Give Ito Feedback

[github-actions]

	Main	PR
Total	42090	42090
Successful	18250	18251
Failures	23840	23839
Partial Successes1	5385	5385

	Main	PR
Successful	43.3595%	43.3618%
Failures	56.6405%	56.6382%

${\color{lightgreen}Progressions (1)}$

copyselect

QUERY: drop table test3;

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩