Skip to content

cypher_vle: add ORDER BY to non-deterministic RETURN queries#2434

Open
jrgemignani wants to merge 1 commit into
apache:masterfrom
jrgemignani:stabilize_cypher_vle_regression_tests
Open

cypher_vle: add ORDER BY to non-deterministic RETURN queries#2434
jrgemignani wants to merge 1 commit into
apache:masterfrom
jrgemignani:stabilize_cypher_vle_regression_tests

Conversation

@jrgemignani

Copy link
Copy Markdown
Contributor

Several VLE regression queries RETURN multiple rows without an ORDER BY, so their row order depends on traversal/scan order and can vary between runs and platforms. Add ORDER BY ASC to those queries (on the path, edge-list, or graphid as appropriate) so the expected output is stable. The queries are pinned by path (p), edge list (e), or graphid (id(u)/id(v)/id(e[n])) depending on what each RETURN projects.

Full audit of cypher_vle: all 38 multi-row result blocks were checked. After this change, every multi-row RETURN is deterministically ordered except the two SELECT * FROM show_list_use_vle('list01') calls, which are already deterministic because the function body orders its results with RETURN v ORDER BY id(v) (added in #2417); their result blocks are unchanged by this commit.

This is a test-only change (regress/sql/cypher_vle.sql and regress/expected/cypher_vle.out); no extension C code or SQL is modified. Row counts are unchanged (pure reordering).

All 37 regression tests pass (installcheck) on PostgreSQL 18.3.

Co-authored-by: GitHub Copilot noreply@github.com

modified: regress/expected/cypher_vle.out
modified: regress/sql/cypher_vle.sql

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR makes cypher_vle regression outputs stable by ensuring multi-row RETURN queries are deterministically ordered, avoiding platform-/run-dependent row ordering from traversal/scan order.

Changes:

  • Added explicit ORDER BY ... ASC clauses to multi-row RETURN queries in regress/sql/cypher_vle.sql.
  • Updated regress/expected/cypher_vle.out to reflect the resulting row reordering (no row-count changes).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
regress/sql/cypher_vle.sql Adds deterministic ORDER BY ... ASC to previously non-deterministic multi-row RETURN queries.
regress/expected/cypher_vle.out Refreshes expected output to match the new deterministic ordering.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Several VLE regression queries RETURN multiple rows without an ORDER BY,
so their row order depends on traversal/scan order and can vary between
runs and platforms. Add ORDER BY ASC to those queries (on the path,
edge-list, or graphid as appropriate) so the expected output is stable.
The queries are pinned by path (p), edge list (e), or graphid
(id(u)/id(v)/id(e[n])) depending on what each RETURN projects.

Full audit of cypher_vle: all 38 multi-row result blocks were checked.
After this change, every multi-row RETURN is deterministically ordered
except the two SELECT * FROM show_list_use_vle('list01') calls, which are
already deterministic because the function body orders its results with
RETURN v ORDER BY id(v) (added in apache#2417); their result blocks are
unchanged by this commit.

This is a test-only change (regress/sql/cypher_vle.sql and
regress/expected/cypher_vle.out); no extension C code or SQL is modified.
Row counts are unchanged (pure reordering).

All 37 regression tests pass (installcheck) on PostgreSQL 18.3.

Co-authored-by: GitHub Copilot <noreply@github.com>

modified:   regress/expected/cypher_vle.out
modified:   regress/sql/cypher_vle.sql
@jrgemignani jrgemignani force-pushed the stabilize_cypher_vle_regression_tests branch from 581ab74 to 25c66c0 Compare June 9, 2026 17:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants