Skip to content

test no-op layout string#2805

Open
jycor wants to merge 1 commit into
mainfrom
james/layout
Open

test no-op layout string#2805
jycor wants to merge 1 commit into
mainfrom
james/layout

Conversation

@jycor

@jycor jycor commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@github-actions

github-actions Bot commented Jun 4, 2026

Copy link
Copy Markdown
Contributor
Main PR
covering_index_scan_postgres 1841.24/s 1845.85/s +0.2%
groupby_scan_postgres 129.93/s 124.81/s -4.0%
index_join_postgres 635.10/s 632.98/s -0.4%
index_join_scan_postgres 791.34/s 785.69/s -0.8%
index_scan_postgres 23.22/s 25.25/s +8.7%
oltp_delete_insert_postgres 781.00/s 747.94/s -4.3%
oltp_insert 677.45/s 666.93/s -1.6%
oltp_point_select 2864.05/s 2779.02/s -3.0%
oltp_read_only 2915.82/s 2846.56/s -2.4%
oltp_read_write 2303.05/s 2335.77/s +1.4%
oltp_update_index 704.84/s 707.36/s +0.3%
oltp_update_non_index 724.98/s 724.07/s -0.2%
oltp_write_only 1709.30/s 1654.19/s -3.3%
select_random_points 1844.79/s 1826.13/s -1.1%
select_random_ranges 1095.58/s 1094.32/s -0.2%
table_scan_postgres 22.27/s 24.08/s +8.1%
types_delete_insert_postgres 735.16/s 733.92/s -0.2%
types_table_scan_postgres 9.70/s ${\color{lightgreen}10.70/s}$ ${\color{lightgreen}+10.3\%}$

@itoqa

itoqa Bot commented Jun 4, 2026

Copy link
Copy Markdown

Ito Test Report ❌

12 test cases ran. 4 failed, 8 passed.

Overall, the unified run failed with 12 total tests (8 passed, 4 failed) and confirmed PR-introduced production defects centered on DateStyle handling, including medium-severity contract drift and a high-severity legacy compatibility regression. The key finding is that startup/session DateStyle negotiation and input parsing still accept and honor non-ISO styles (SQL/Postgres/German, MDY/DMY/YMD), but temporal text output paths are hardcoded to ISO (via getLayoutStringFormat used by date_out/timestamp_out), which breaks round-trip and strict parser expectations for DateStyle-aware clients even though binary encoding and mixed binary-text semantic values remained stable.

❌ Failed (4)
Category Summary Screenshot
Session 🟠 Date input parsing honors DateStyle ordering, but date/timestamp text output ignores DateStyle and remains ISO, causing contract drift. SESSION-3
Style 🟠 Metadata/payload DateStyle contract drift is present in production code. STYLE-4
Style ⚠️ Legacy non-ISO DateStyle compatibility regressed without migration signaling. STYLE-5
Wire 🟠 Startup-negotiated non-ISO DateStyle is persisted, but temporal text serialization is still hard-wired to ISO, breaking client parsing contracts. WIRE-3
🟠 DateStyle round-trip contract breaks between input and output
  • What failed: Input-side parsing follows configured DateStyle ordering, but output-side rendering always uses ISO format. Expected behavior is that input and output semantics stay aligned for the same session DateStyle.
  • Impact: Clients that rely on session DateStyle for round-trip parsing can mis-handle temporal text values. This creates integration errors in DateStyle-aware workflows without fully blocking basic query execution.
  • Steps to reproduce:
    1. Set DateStyle to a non-default ordering such as German, DMY.
    2. Cast an ambiguous date value like '02/03/2023'::date and verify it is interpreted using DMY ordering.
    3. Select the value back as text and compare output formatting against the configured DateStyle semantics.
  • Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
  • Code analysis: I inspected server/functions/date.go and server/functions/timestamp.go. date_in uses DateStyle-aware parse-order selection, but getLayoutStringFormat no longer branches on DateStyle and always returns ISO layouts; date_out depends on that function, so output formatting diverges from input semantics.
  • Why this is likely a bug: Production code applies DateStyle to date input parsing but not to output formatting, creating an internally inconsistent contract in normal session behavior.

Relevant code:

server/functions/date.go (lines 45-56)

Callable: func(ctx *sql.Context, _ [2]*pgtypes.DoltgresType, val any) (any, error) {
	input := val.(string)
	formatsInOrder := getDateStyleInputFormat(ctx)
	var date pgdate.Date
	var err error
	for _, format := range formatsInOrder {
		date, _, err = pgdate.ParseDate(time.Now(), format, input)
		if err == nil {
			return date.ToTime()
		}
	}
	return nil, err
},

server/functions/timestamp.go (lines 193-221)

func getLayoutStringFormat(ctx *sql.Context, dateOnly bool) string {
	//layout := getDateStyleOutputFormat(ctx)
	//switch layout {
	//case DateStyleISO:
	// ... DateStyle-specific branches commented out ...
	//}
	// shouldn't happen but return default
	if dateOnly {
		return dateStyleFormatDateOnly_ISO
	}
	return dateStyleFormat_ISO
}

server/functions/date.go (lines 66-68)

Callable: func(ctx *sql.Context, _ [2]*pgtypes.DoltgresType, val any) (any, error) {
	return FormatDateTimeWithBC(val.(time.Time), getLayoutStringFormat(ctx, true), false), nil
},
🟠 DateStyle metadata and payload contract drift
  • What failed: Session metadata reports a non-ISO DateStyle, but emitted temporal text remains ISO-formatted, so metadata and payload semantics diverge.
  • Impact: Integrations that branch parser behavior on negotiated DateStyle can mis-handle or reject temporal payloads. Users can work around this by forcing ISO expectations, but contract consistency is broken.
  • Steps to reproduce:
    1. Set DateStyle to SQL, YMD and verify SHOW DateStyle returns that value.
    2. Query DATE and TIMESTAMP values through text DataRow output.
    3. Compare returned text shape with SQL-style expectations.
  • Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
  • Code analysis: I reviewed startup parameter initialization, DateStyle validation, and temporal output formatting paths. The server stores and reports non-ISO DateStyle values, but getLayoutStringFormat now returns ISO-only layouts, creating a direct metadata-versus-payload mismatch.
  • Why this is likely a bug: Production code simultaneously accepts/reports non-ISO DateStyle and emits ISO-only temporal text, which violates a single-session formatting contract.

Relevant code:

server/connection_handler.go (lines 299-309)

func (h *ConnectionHandler) chooseInitialParameters(startupMessage *pgproto3.StartupMessage) error {
    for name, value := range startupMessage.Parameters {
        switch strings.ToLower(name) {
        case "datestyle":
            err := h.doltgresHandler.InitSessionParameterDefault(context.Background(), h.mysqlConn, "DateStyle", value)
            if err != nil {
                return err
            }
        }
    }

server/functions/timestamp.go (lines 193-222)

func getLayoutStringFormat(ctx *sql.Context, dateOnly bool) string {
    //layout := getDateStyleOutputFormat(ctx)
    //switch layout {
    //case DateStyleISO:
    // ... SQL/Postgres/German branches commented out ...
    //}
    if dateOnly {
        return dateStyleFormatDateOnly_ISO
    }
    return dateStyleFormat_ISO
}

server/config/parameters_list.go (lines 720-746)

values := strings.Split(strings.ReplaceAll(strings.ToLower(newVal), " ", ""), ",")
for _, value := range values {
    switch value {
    case "iso":
        ds = "ISO"
    case "sql":
        ds = "SQL"
    case "postgres":
        ds = "Postgres"
    case "german":
        ds = "German"
⚠️ Legacy DateStyle output compatibility regression
  • What failed: Non-ISO DateStyle values are still accepted, but output layout branches for those styles are effectively removed, so upgraded behavior breaks legacy format expectations with no explicit migration/error signal.
  • Impact: Legacy clients can fail parsing or business logic immediately after upgrade when they depend on non-ISO temporal text contracts. There is no server-side migration signal to prevent silent incompatibility.
  • Steps to reproduce:
    1. Use a client flow that historically relied on non-ISO DateStyle output.
    2. Set DateStyle to SQL, Postgres, or German values accepted by validation.
    3. Execute temporal text queries and compare outputs to prior non-ISO layout contracts.
  • Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
  • Code analysis: I inspected DateStyle validation and output formatter logic, plus PR diff context. Validation still permits SQL/Postgres/German styles, but formatter selection is collapsed to ISO-only returns; this is a backward-compat behavior regression in production code.
  • Why this is likely a bug: The code preserves acceptance of legacy DateStyle options but removes corresponding output behavior, creating a real compatibility break rather than a test artifact.

Relevant code:

server/config/parameters_list.go (lines 723-746)

switch value {
case "iso":
    ds = "ISO"
case "sql":
    ds = "SQL"
case "postgres":
    ds = "Postgres"
case "german":
    ds = "German"
    if !doSet {
        do = "DMY"
    }

server/functions/timestamp.go (lines 194-216)

//layout := getDateStyleOutputFormat(ctx)
//switch layout {
//case DateStyleISO:
//    return dateStyleFormat_ISO
//case DateStyleSQL:
//    return dateStyleFormat_SQL
//case DateStylePostgres:
//    return dateStyleFormat_Postgres
//case DateStyleGerman:
//    return dateStyleFormat_German
//}

server/functions/timestamp.go (lines 217-222)

// shouldn't happen but return default
if dateOnly {
    return dateStyleFormatDateOnly_ISO
}
return dateStyleFormat_ISO
🟠 DateStyle contract drift breaks parser
  • What failed: The session reports a non-ISO DateStyle contract, but returned temporal text stays ISO-formatted, so strict DateStyle-aware clients fail to parse values they were told to expect.
  • Impact: Clients that rely on negotiated non-ISO DateStyle can fail parsing timestamp text values in normal integration flows. Users can work around this only by forcing ISO expectations client-side.
  • Steps to reproduce:
    1. Open a connection with startup parameter datestyle=Postgres, MDY.
    2. Run SHOW DateStyle in that same session and confirm the negotiated value.
    3. Query temporal text values and parse them with a Postgres-style parser to observe failures on ISO-shaped output.
  • Stub / mock context: SCRAM authentication was temporarily bypassed in server/authentication_scram.go, and local temporal fixtures were seeded to reproduce startup DateStyle negotiation and validate the text-serialization defect deterministically.
  • Code analysis: chooseInitialParameters persists startup datestyle into session state, but getLayoutStringFormat ignores session DateStyle and always returns ISO. timestamp_out uses that fixed layout for emitted text, creating metadata/payload contract drift.
  • Why this is likely a bug: Production code accepts and stores non-ISO DateStyle in session state but deterministically emits ISO timestamp text, which directly violates the negotiated format contract.

Relevant code:

server/connection_handler.go (lines 299-309)

func (h *ConnectionHandler) chooseInitialParameters(startupMessage *pgproto3.StartupMessage) error {
	for name, value := range startupMessage.Parameters {
		// TODO: handle other parameters defined in StartupMessage
		switch strings.ToLower(name) {
		case "datestyle":
			err := h.doltgresHandler.InitSessionParameterDefault(context.Background(), h.mysqlConn, "DateStyle", value)
			if err != nil {
				return err
			}
		}
	}

server/functions/timestamp.go (lines 193-221)

func getLayoutStringFormat(ctx *sql.Context, dateOnly bool) string {
	//layout := getDateStyleOutputFormat(ctx)
	//switch layout {
	//case DateStyleISO:
	//	if dateOnly {
	//		return dateStyleFormatDateOnly_ISO
	//	}
	//	return dateStyleFormat_ISO
	// ...non-ISO branches commented out...
	if dateOnly {
		return dateStyleFormatDateOnly_ISO
	}
	return dateStyleFormat_ISO
}

server/functions/timestamp.go (lines 63-71)

var timestamp_out = framework.Function1{
	Name:       "timestamp_out",
	Return:     pgtypes.Cstring,
	Parameters: [1]*pgtypes.DoltgresType{pgtypes.Timestamp},
	Strict:     true,
	Callable: func(ctx *sql.Context, _ [2]*pgtypes.DoltgresType, val any) (any, error) {
		t := val.(time.Time)
		return FormatDateTimeWithBC(t, getLayoutStringFormat(ctx, false), false), nil
	},
}
✅ Passed (8)
Category Summary Screenshot
Session SHOW DateStyle changed across ISO/SQL/Postgres settings while TIMESTAMP text output stayed constant in ISO shape. SESSION-2
Session Startup DateStyle negotiation was accepted, and immediate temporal text output matched ISO-style session metadata. SESSION-4
Style Parser-contract mismatch precondition exists in code paths. STYLE-1
Style Session DateStyle accepts non-ISO values while text output remains ISO. STYLE-2
Style TIMESTAMP text output stays ISO under Postgres DateStyle. STYLE-3
Wire Binary wire encoding stayed stable while text output differed under non-ISO DateStyle, matching expected behavior for this check. WIRE-1
Wire Strict parsing correctly surfaced format mismatch errors instead of silently coercing mismatched temporal text. WIRE-2
Wire Mixed text and binary temporal values normalized to the same logical timestamps, so no semantic drift was found. WIRE-4

Commit: 9d04869

View Full Run

Tell us how we did: Give Ito Feedback

@github-actions

github-actions Bot commented Jun 4, 2026

Copy link
Copy Markdown
Contributor
Main PR
Total 42090 42090
Successful 18203 18037
Failures 23887 24053
Partial Successes1 5374 5374
Main PR
Successful 43.2478% 42.8534%
Failures 56.7522% 57.1466%

${\color{red}Regressions (172)}$

date

QUERY:          SELECT DATE_TRUNC('MILLENNIUM', TIMESTAMP '1970-03-20 04:30:00.00000');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Jan 01 00:00:00 1001"}
    Doltgres:
        {1001-01-01 00:00:00 +0000 UTC}

QUERY:          SELECT DATE_TRUNC('CENTURY', TIMESTAMP '1970-03-20 04:30:00.00000');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Tue Jan 01 00:00:00 1901"}
    Doltgres:
        {1901-01-01 00:00:00 +0000 UTC}

QUERY:          SELECT DATE_TRUNC('CENTURY', DATE '1970-03-20');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Tue Jan 01 00:00:00 1901 PST"}
    Doltgres:
        {1901-01-01 00:00:00 -0800 -0800}

QUERY:          SELECT DATE_TRUNC('CENTURY', DATE '2004-08-10');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Mon Jan 01 00:00:00 2001 PST"}
    Doltgres:
        {2001-01-01 00:00:00 -0800 -0800}

QUERY:          SELECT DATE_TRUNC('DECADE', DATE '1993-12-25');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Mon Jan 01 00:00:00 1990 PST"}
    Doltgres:
        {1990-01-01 00:00:00 -0800 -0800}

horology

QUERY:          SELECT timestamp with time zone '20011227 040506+08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Wed Dec 26 12:05:06 2001 PST"}
    Doltgres:
        {2001-12-26 12:05:06 -0800 -0800}

QUERY:          SELECT timestamp with time zone '20011227 040506-08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Dec 27 04:05:06 2001 PST"}
    Doltgres:
        {2001-12-27 04:05:06 -0800 -0800}

QUERY:          SELECT timestamp with time zone '20011227 040506.789+08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Wed Dec 26 12:05:06.789 2001 PST"}
    Doltgres:
        {2001-12-26 12:05:06.789 -0800 -0800}

QUERY:          SELECT timestamp with time zone '20011227 040506.789-08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Dec 27 04:05:06.789 2001 PST"}
    Doltgres:
        {2001-12-27 04:05:06.789 -0800 -0800}

QUERY:          SELECT timestamp with time zone '20011227T040506+08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Wed Dec 26 12:05:06 2001 PST"}
    Doltgres:
        {2001-12-26 12:05:06 -0800 -0800}

QUERY:          SELECT timestamp with time zone '20011227T040506-08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Dec 27 04:05:06 2001 PST"}
    Doltgres:
        {2001-12-27 04:05:06 -0800 -0800}

QUERY:          SELECT timestamp with time zone '20011227T040506.789+08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Wed Dec 26 12:05:06.789 2001 PST"}
    Doltgres:
        {2001-12-26 12:05:06.789 -0800 -0800}

QUERY:          SELECT timestamp with time zone '20011227T040506.789-08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Dec 27 04:05:06.789 2001 PST"}
    Doltgres:
        {2001-12-27 04:05:06.789 -0800 -0800}

QUERY:          SELECT timestamp with time zone '2001-12-27 04:05:06.789-08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Dec 27 04:05:06.789 2001 PST"}
    Doltgres:
        {2001-12-27 04:05:06.789 -0800 -0800}

QUERY:          SELECT timestamp with time zone '2001/12/27 04:05:06.789-08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Dec 27 04:05:06.789 2001 PST"}
    Doltgres:
        {2001-12-27 04:05:06.789 -0800 -0800}

QUERY:          SELECT timestamp with time zone '12/27/2001 04:05:06.789-08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Dec 27 04:05:06.789 2001 PST"}
    Doltgres:
        {2001-12-27 04:05:06.789 -0800 -0800}

QUERY:          SELECT timestamp with time zone 'J2452271+08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Wed Dec 26 08:00:00 2001 PST"}
    Doltgres:
        {2001-12-26 08:00:00 -0800 -0800}

QUERY:          SELECT timestamp with time zone 'J2452271-08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Dec 27 00:00:00 2001 PST"}
    Doltgres:
        {2001-12-27 00:00:00 -0800 -0800}

QUERY:          SELECT timestamp with time zone 'J2452271 04:05:06+08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Wed Dec 26 12:05:06 2001 PST"}
    Doltgres:
        {2001-12-26 12:05:06 -0800 -0800}

QUERY:          SELECT timestamp with time zone 'J2452271 04:05:06-08';
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Dec 27 04:05:06 2001 PST"}
    Doltgres:
        {2001-12-27 04:05:06 -0800 -0800}

QUERY:          SELECT date '1981-02-03' + time '04:05:06' AS "Date + Time";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Tue Feb 03 04:05:06 1981"}
    Doltgres:
        {1981-02-03 04:05:06 +0000 UTC}

QUERY:          SELECT date '1991-02-03' + time with time zone '04:05:06 PST' AS "Date + Time PST";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sun Feb 03 04:05:06 1991 PST"}
    Doltgres:
        {1991-02-03 04:05:06 -0800 -0800}

QUERY:          SELECT date '2001-02-03' + time with time zone '04:05:06 UTC' AS "Date + Time UTC";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Fri Feb 02 20:05:06 2001 PST"}
    Doltgres:
        {2001-02-02 20:05:06 -0800 -0800}

QUERY:          SELECT date '1991-02-03' - time '04:05:06' AS "Subtract Time";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sat Feb 02 19:54:54 1991"}
    Doltgres:
        {1991-02-02 19:54:54 +0000 UTC}

QUERY:          SELECT timestamp without time zone '1996-03-01' - interval '1 second' AS "Feb 29";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Feb 29 23:59:59 1996"}
    Doltgres:
        {1996-02-29 23:59:59 +0000 UTC}

QUERY:          SELECT timestamp without time zone '1999-03-01' - interval '1 second' AS "Feb 28";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sun Feb 28 23:59:59 1999"}
    Doltgres:
        {1999-02-28 23:59:59 +0000 UTC}

QUERY:          SELECT timestamp without time zone '2000-03-01' - interval '1 second' AS "Feb 29";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Tue Feb 29 23:59:59 2000"}
    Doltgres:
        {2000-02-29 23:59:59 +0000 UTC}

QUERY:          SELECT date '1994-01-01' + time '11:00' AS "Jan_01_1994_11am";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sat Jan 01 11:00:00 1994"}
    Doltgres:
        {1994-01-01 11:00:00 +0000 UTC}

QUERY:          SELECT date '1994-01-01' + time '10:00' AS "Jan_01_1994_10am";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sat Jan 01 10:00:00 1994"}
    Doltgres:
        {1994-01-01 10:00:00 +0000 UTC}

QUERY:          SELECT date '1994-01-01' + timetz '11:00-5' AS "Jan_01_1994_8am";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sat Jan 01 08:00:00 1994 PST"}
    Doltgres:
        {1994-01-01 08:00:00 -0800 -0800}

QUERY:          SELECT timestamp with time zone '1996-03-01' - interval '1 second' AS "Feb 29";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Feb 29 23:59:59 1996 PST"}
    Doltgres:
        {1996-02-29 23:59:59 -0800 -0800}

QUERY:          SELECT timestamp with time zone '1999-03-01' - interval '1 second' AS "Feb 28";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sun Feb 28 23:59:59 1999 PST"}
    Doltgres:
        {1999-02-28 23:59:59 -0800 -0800}

QUERY:          SELECT timestamp with time zone '2000-03-01' - interval '1 second' AS "Feb 29";
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Tue Feb 29 23:59:59 2000 PST"}
    Doltgres:
        {2000-02-29 23:59:59 -0800 -0800}

QUERY:          SELECT to_timestamp('2011$03!18 23_38_15', 'YYYY-MM-DD HH24:MI:SS');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Fri Mar 18 23:38:15 2011 PDT"}
    Doltgres:
        {2011-03-18 23:38:15 -0700 -0700}

QUERY:          SELECT to_timestamp('1985 January 12', 'YYYY FMMonth DD');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sat Jan 12 00:00:00 1985 PST"}
    Doltgres:
        {1985-01-12 00:00:00 -0800 -0800}

QUERY:          SELECT to_timestamp('1985 FMMonth 12', 'YYYY "FMMonth" DD');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sat Jan 12 00:00:00 1985 PST"}
    Doltgres:
        {1985-01-12 00:00:00 -0800 -0800}

QUERY:          SELECT to_timestamp('1985 \ 12', 'YYYY \\ DD');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sat Jan 12 00:00:00 1985 PST"}
    Doltgres:
        {1985-01-12 00:00:00 -0800 -0800}

QUERY:          SELECT to_timestamp('My birthday-> Year: 1976, Month: May, Day: 16',
                    '"My birthday-> Year:" YYYY, "Month:" FMMonth, "Day:" DD');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Sun May 16 00:00:00 1976 PDT"}
    Doltgres:
        {1976-05-16 00:00:00 -0700 -0700}

QUERY:          SELECT to_timestamp('15 "text between quote marks" 98 54 45',
                    E'HH24 "\\"text between quote marks\\"" YY MI SS');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Thu Jan 01 15:54:45 1998 PST"}
    Doltgres:
        {1998-01-01 15:54:45 -0800 -0800}

QUERY:          SELECT to_timestamp('05121445482000', 'MMDDHH24MISSYYYY');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"Fri May 12 14:45:48 2000 PDT"}
    Doltgres:
        {2000-05-12 14:45:48 -0700 -0700}

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

subselect

QUERY: select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);

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. ↩

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@jycor