Skip to content

Rebrand for IvorySQL distribution: ivy_mooncake#1

Open
NotHimmel wants to merge 1 commit intoIvorySQL:mainfrom
NotHimmel:main
Open

Rebrand for IvorySQL distribution: ivy_mooncake#1
NotHimmel wants to merge 1 commit intoIvorySQL:mainfrom
NotHimmel:main

Conversation

@NotHimmel
Copy link
Copy Markdown

The repo is renamed "ivy_mooncake" (GitHub fork name, README title); the extension, cdylib, Cargo package, and SQL-level identifiers all stay "pg_mooncake" so SQL written against pg_mooncake keeps working. Mirrors the ivy_duckdb pattern (the IvorySQL pg_duckdb fork installs as the pg_duckdb extension).

Changes vs upstream Mooncake-Labs/pg_mooncake (b7c67e0):

Submodules - all three forked to IvorySQL with ivy_* path names:

  • pg_duckdb -> ivy_duckdb (IvorySQL/ivy_duckdb)
  • moonlink -> ivy_moonlink (IvorySQL/ivy_moonlink)
  • duckdb_mooncake -> ivy_duckdb_mooncake (IvorySQL/ivy_duckdb_mooncake; pinned at the same upstream SHA bd9e5f3a)

Path references following the renamed submodules:

  • Cargo.toml: moonlink_*.path = "ivy_moonlink/..."
  • Makefile: targets ivy_duckdb, ivy_duckdb_mooncake
  • .vscode/c_cpp_properties.json: ${workspaceFolder}/ivy_duckdb/**
  • Dockerfile: COPY ivy_moonlink ivy_moonlink

Repo identity:

  • README rewritten as "IvorySQL distribution of pg_mooncake" framing, clone URL IvorySQL/ivy_mooncake.git; SQL examples and shared_preload_libraries stay pg_mooncake

Toolchain:

  • rust-toolchain 1.88.0 -> 1.91.1 (required by aws-sdk-* MSRV in moonlink_service via the bgworker feature)

Intentionally NOT renamed (preserved at upstream values for SQL/ABI compatibility):

  • Extension name, cdylib library, Cargo package -> pg_mooncake
  • module_pathname='pg_mooncake', requires='pg_duckdb' in control file
  • DuckDB-side names: mooncake schema, mooncake access method, pgmooncake_* C symbols, INSTALL mooncake FROM community

Verified end-to-end: make ivy_duckdb installs pg_duckdb.so; cargo pgrx regress --resetdb passes 3/3 (setup, partitioned_table, sanity) under rust 1.91.1 with
shared_preload_libraries='pg_duckdb,pg_mooncake'.

The repo is renamed "ivy_mooncake" (GitHub fork name, README title); the
extension, cdylib, Cargo package, and SQL-level identifiers all stay
"pg_mooncake" so SQL written against pg_mooncake keeps working. Mirrors
the ivy_duckdb pattern (the IvorySQL pg_duckdb fork installs as the
pg_duckdb extension).

Changes vs upstream Mooncake-Labs/pg_mooncake (b7c67e0):

Submodules - all three forked to IvorySQL with ivy_* path names:
- pg_duckdb -> ivy_duckdb (IvorySQL/ivy_duckdb)
- moonlink -> ivy_moonlink (IvorySQL/ivy_moonlink)
- duckdb_mooncake -> ivy_duckdb_mooncake (IvorySQL/ivy_duckdb_mooncake;
  pinned at the same upstream SHA bd9e5f3a)

Path references following the renamed submodules:
- Cargo.toml: moonlink_*.path = "ivy_moonlink/..."
- Makefile: targets ivy_duckdb, ivy_duckdb_mooncake
- .vscode/c_cpp_properties.json: \${workspaceFolder}/ivy_duckdb/**
- Dockerfile: COPY ivy_moonlink ivy_moonlink

Repo identity:
- README rewritten as "IvorySQL distribution of pg_mooncake" framing,
  clone URL IvorySQL/ivy_mooncake.git; SQL examples and
  shared_preload_libraries stay pg_mooncake

Toolchain:
- rust-toolchain 1.88.0 -> 1.91.1 (required by aws-sdk-* MSRV in
  moonlink_service via the bgworker feature)

Intentionally NOT renamed (preserved at upstream values for SQL/ABI
compatibility):
- Extension name, cdylib library, Cargo package -> pg_mooncake
- module_pathname='pg_mooncake', requires='pg_duckdb' in control file
- DuckDB-side names: mooncake schema, mooncake access method,
  pgmooncake_* C symbols, INSTALL mooncake FROM community

Verified end-to-end: make ivy_duckdb installs pg_duckdb.so;
cargo pgrx regress --resetdb passes 3/3 (setup, partitioned_table,
sanity) under rust 1.91.1 with
shared_preload_libraries='pg_duckdb,pg_mooncake'.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.

1 participant