Advance master branch to Apache AGE version 1.8.0

[jrgemignani]

Updated the following files to advance the Apache AGE version to 1.8.0

modified: META.json
modified: README.md
modified: RELEASE
renamed: age--1.7.0--y.y.y.sql -> age--1.7.0--1.8.0.sql
modified: age.control
modified: docker/Dockerfile
new file: age--1.8.0--y.y.y.sql

[Copilot]

Pull request overview

Updates the repository metadata and packaging artifacts to advance the Apache AGE master branch extension version to 1.8.0 (PG18), including release notes and upgrade-script naming.

Changes:

• Bump the extension default version to 1.8.0 and update visible version indicators (README badge, RELEASE notes).
• Update PGXN-style metadata (META.json) for the 1.8.0 release.
• Ship the 1.7.0 → 1.8.0 upgrade path via a dedicated upgrade script and update the Docker image to reference 1.8.0 artifacts.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
RELEASE	Updates the master-branch release notes header/content for 1.8.0.
README.md	Updates the release badge to v1.8.0.
META.json	Updates extension metadata to 1.8.0 and adjusts PostgreSQL runtime requirement.
docker/Dockerfile	Updates which extension SQL file is copied into the final image.
age.control	Sets default_version to 1.8.0.
age--1.7.0--1.8.0.sql	Converts/ships the 1.7.0→1.8.0 upgrade script content and header.

Comments suppressed due to low confidence (1)

age--1.7.0--1.8.0.sql:24

• With default_version now 1.8.0, the Makefile’s upgrade-regression machinery expects a new upgrade template file named age--1.8.0--y.y.y.sql to exist for validating future upgrades. Renaming the prior template into a real 1.7.0→1.8.0 upgrade script is fine, but without adding the new 1.8.0 template, that upgrade test path will be skipped going forward.

---

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

[gregfelice]

Release mechanics look good — version bumps (age.control, META.json, README, Dockerfile), the RELEASE changelog, and the rename of age--1.7.0--y.y.y.sql → age--1.7.0--1.8.0.sql are all correct, and CI is green.

One nit on the newly-added next-version template, age--1.8.0--y.y.y.sql: it carries a stray leading block (a concrete '1.8.0' echo + \quit) prepended above the real '1.X.0' template:

-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "ALTER EXTENSION age UPDATE TO '1.8.0'" to load this file. \quit   <-- stray

--* This is a TEMPLATE for upgrading from the previous version of Apache AGE
...
\echo Use "ALTER EXTENSION age UPDATE TO '1.X.0'" to load this file. \quit

No impact on the 1.8.0 release itself (a y.y.y script is never resolved/sourced). But it's a latent footgun for the next cycle: when this file is renamed to age--1.8.0--1.9.0.sql and changes are appended, that orphan \quit sits above everything and isn't a --* line, so the "REMOVE ALL LINES ABOVE ... that start with --*" instruction won't catch it — the resulting upgrade script would \quit before applying any changes.

Fix is just dropping those 6 lines so the file starts with the --* This is a TEMPLATE ... block, matching the canonical template form. Happy to push it to the branch if that's easier.

[jrgemignani]

@gregfelice Fixed and added the latest PRs to RELEASE as well.

[jrgemignani]

@MuhammadTahaNaveed @gregfelice

PostgreSQL 18 — AGE 1.7.0 → 1.8.0 upgrade validation on real graph data

Verdict: PASS. The age--1.7.0--1.8.0.sql upgrade preserves all existing graph
data and correctly applies the new-version catalog changes. Validated with a real
two-binary upgrade (a 1.7.0 build → the 1.8.0 build from this PR) against PostgreSQL 18.3.

Upgrade script is data-safe by construction

Every top-level statement in age--1.7.0--1.8.0.sql is catalog DDL only:

• 28 × CREATE FUNCTION, 8 × CREATE CAST, 4 × CREATE OPERATOR, 2 × CREATE TYPE
  (vertex, edge), 1 × CREATE AGGREGATE
• a few DROP FUNCTION IF EXISTS + re-CREATE for internal functions whose signatures
  changed (e.g. _agtype_build_vertex/_agtype_build_edge, _label_name, the old age_vle)
• ALTER OPERATOR (selectivity/commutator metadata on existing agtype operators) and COMMENTs
• one DO block that adds an _age_cache_invalidate trigger to each existing label table
  (idempotent; skips the _ag_label_vertex/_ag_label_edge base tables)

There are no INSERT/UPDATE/DELETE/TRUNCATE/ALTER TABLE/DROP TABLE statements
touching label-table rows, so existing graph data cannot be modified or lost by the script.

Test methodology

1. Built and installed real 1.7.0 (commit 858747c7) against PG18; CREATE EXTENSION age (→ 1.7.0).
2. Loaded real data across 2 graphs: 14 vertices / 5 labels, 11 edges / 4 labels, with mixed
   property types (string/int/float/bool/array/nested-object/null), plus a user btree index on a label table.
3. Snapshotted all label-table rows (id[,start_id,end_id],properties ordered by id) plus an
   order-independent MD5 checksum.
4. Installed 1.8.0 (this PR, e6757b99), restarted the server, ran ALTER EXTENSION age UPDATE TO '1.8.0'.
5. Re-snapshotted and compared; verified catalog structure and ran functional queries.

Results

Check	Result
ALTER EXTENSION age UPDATE TO '1.8.0'	Succeeded; extversion → 1.8.0
Graph data integrity	Byte-identical — snapshot diff empty, MD5 unchanged (1d24950e…11e358)
DO-block triggers	_age_cache_invalidate added to all 9 named label tables; 0 on base tables
New catalog objects	vertex/edge types, age_invalidate_graph_cache, age_reduce present
User index	Survived
Queries on migrated data	KNOWS traversal, VLE (*1..n), reduce(), and ::vertex/::edge returns all correct
Post-upgrade DML + cache	New edge fires the trigger; same-session VLE reflects it (cache invalidation works)

Conclusion

The 1.7.0 → 1.8.0 upgrade path is correct and non-destructive on populated databases. No issues found.