💡 Verification agent

#!/bin/bash
set -euo pipefail
# Does contrib/Makefile include uuid-ossp?
fd -a contrib/Makefile
if fd -a contrib/Makefile >/dev/null; then
  rg -n "SUBDIRS|DIRS" contrib/Makefile -A2 -B2
  rg -n "uuid-ossp" contrib/Makefile || echo "uuid-ossp not listed in contrib/Makefile"
else
  echo "contrib/Makefile not found"
fi

Remove duplicate recursion for contrib/uuid-ossp

The contrib/Makefile already adds uuid-ossp to SUBDIRS/ALWAYS_SUBDIRS, so having it explicitly in the top‐level recurse call will double-build/clean/test. Please remove the extra entries at lines 11, 48, and 98 in GNUmakefile.in.

• GNUmakefile.in:11,48,98

  -$(call recurse,all install,src config contrib/ivorysql_ora contrib/uuid-ossp contrib/ora_btree_gist contrib/ora_btree_gin)
  +$(call recurse,all install,src config contrib/ivorysql_ora contrib/ora_btree_gist contrib/ora_btree_gin)

In GNUmakefile.in at lines 11, 48, and 98, the contrib/uuid-ossp directory is
redundantly included in the recurse calls, causing duplicate build, clean, and
test actions. Remove the explicit mentions of contrib/uuid-ossp from these lines
to avoid double-processing since it is already handled by the contrib/Makefile's
SUBDIRS/ALWAYS_SUBDIRS settings.

Could you clarify why this file was modified？

Hi, @OreoYang
The modification of this line is to automatically compile the uuid-ossp plugin with the aim of automatically loading the plugin for using the sys_guid function.
If "uuid - ossp" is removed, the following error message will be reported when executing initdb, indicating that uuid - ossp has not been compiled correctly.

That's make sense.

Hello @Carlos-Chong200 @OreoYang

Question has raised in the past about UUID function "in-core" or not (on psql-hackers). OSSP was on the topic.

It's a bit surprising to have dependency on contrib/extensions for initdb, does it make sense to make requirement closer to postgres kernel by moving required functions outside of contrib/ ?

Hi, Cedric,

In addition to uuid extension, there are other extensions that are created in initdb, like plisql, ivorysql_ora.
This is IvorySQL's design and we try to develop Oracle compatibility features in extensions for flexibility.

💡 Verification agent

 --
 -- Plugin uuid-ossp
 --
-CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
+RESET search_path;          -- ensure extension installs into public
+CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
+SET search_path TO sys;     -- restore Oracle compatibility path

#!/bin/bash
set -euo pipefail
# Locate control file and check 'relocatable' and 'default_version'
fd -a uuid-ossp.control | tee /dev/stderr
if fd -a uuid-ossp.control >/dev/null; then
  rg -n "^(relocatable|default_version)\s*=" $(fd -a uuid-ossp.control)
else
  echo "uuid-ossp.control not found under contrib/uuid-ossp" >&2
fi

#!/bin/bash
set -euo pipefail

# Find the uuid-ossp control file
control_file=$(fd -a uuid-ossp.control || true)
if [[ -z "$control_file" ]]; then
  echo "uuid-ossp.control not found in the repo" >&2
  exit 1
fi

echo "Found control file: $control_file"

# Print relocatable and default_version settings
rg -n "^(relocatable|default_version)\s*=" "$control_file"

Ensure uuid-ossp Installs into the Public Schema
The CREATE EXTENSION call currently runs with search_path=sys, so all objects (e.g., uuid_generate_*) land in the sys schema. To avoid polluting sys and breaking clients/tests that expect these functions in the default path, install the extension into public.

We’ve confirmed from contrib/uuid-ossp/uuid-ossp.control that

• default_version = '1.1'
• relocatable = true

You can address this in one of two ways:

• Reset the search_path around the CREATE:

--
-- Plugin uuid-ossp
--
- CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
+ RESET search_path;                     -- ensure objects go into public
+ CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
+ SET search_path TO sys;                -- restore Oracle-compat path

• Or, since the extension is relocatable, force it into public:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp" SCHEMA public;

Pick the approach that best fits your code-style guidelines.

In contrib/ivorysql_ora/preload_ora_misc.sql around lines 16 to 20, the CREATE
EXTENSION for uuid-ossp currently installs objects into the sys schema due to
the search_path setting. To fix this, modify the CREATE EXTENSION statement to
explicitly install the extension into the public schema by adding "SCHEMA
public" to the command, ensuring the uuid_generate_* functions and related
objects reside in the public schema and avoid polluting sys.

You need also change corresponding expected/ivy_uuid_ossp.out, otherwise the regression test would fail.

⚠️ Potential issue

Bug: OSSP uuid_t is an opaque handle; memcpy does not yield the UUID bytes

With OSSP, uuid_t is not a 16-byte binary UUID. You must export the generated UUID to binary via uuid_export; memcpy-ing from the uuid_t object produces invalid results.

Apply:

 #ifdef HAVE_UUID_OSSP
-    uuid_t      *uuid;
-    uuid_rc_t   rc;
-    uuid = get_cached_uuid_t(0);
-    rc = uuid_make(uuid, UUID_MAKE_V4, NULL, NULL);
-    if (rc != UUID_RC_OK) {
-        pguuid_complain(rc);
-    }
-    memcpy(VARDATA(result), (unsigned char *)uuid, SYS_GUID_LENGTH);
+    uuid_t      *uuid;
+    uuid_rc_t   rc;
+    void       *ptr = VARDATA(result);
+    size_t      len = SYS_GUID_LENGTH;
+
+    uuid = get_cached_uuid_t(0);
+    rc = uuid_make(uuid, UUID_MAKE_V4, NULL, NULL);
+    if (rc != UUID_RC_OK)
+        pguuid_complain(rc);
+    rc = uuid_export(uuid, UUID_FMT_BIN, &ptr, &len);
+    if (rc != UUID_RC_OK || len != SYS_GUID_LENGTH)
+        pguuid_complain(rc);

In contrib/uuid-ossp/uuid-ossp.c around lines 565 to 574, the code incorrectly
uses memcpy to copy the UUID from the opaque uuid_t handle, which does not
contain raw UUID bytes. To fix this, replace the memcpy call with a call to
uuid_export to convert the uuid_t to a 16-byte binary UUID before copying it
into the result buffer.