SQL function to access to `creating_extension`
Hi,
I propose to introduce `pg_creating_extension()` function that would return
the OID of the extension being currently created (or `null` if none is).
The core motivation for it is to be able to establish data provenance in
tables created by extensions to be used in `pg_extension_config_dump`
configuration. This way, even if a secondary extension inserts data, it can
still be excluded from the dump by tracking data provenance in a column
with a default. Something like
```
create table my_config (
--- ...
extension_provenance oid default pg_creating_extension()
)
```This would allow for a generalized exclusion in pg_extension_config_dump.
I've attached a draft patch for this simple function. I am happy to
finalize it with tests and documentation if there is a consensus on the
shape.
--
Founder at Omnigres
https://omnigres.com
Attachments:
v1-0001-pg_creating_extension-to-inspect-if-an-extension-is-.patchapplication/octet-stream; name=v1-0001-pg_creating_extension-to-inspect-if-an-extension-is-.patchDownload
From 1954ffc0dad2507408702ca12092abc4e5b8f45a Mon Sep 17 00:00:00 2001
From: Yurii Rashkovskii <yrashk@gmail.com>
Date: Fri, 18 Apr 2025 17:54:58 -0700
Subject: [PATCH] pg_creating_extension() to inspect if an extension is being
created.
This allows for much better control of what data is subject to
`pg_extension_config_dump` as such data provenance can be established
using this function.
---
src/backend/commands/extension.c | 10 ++++++++++
src/include/catalog/pg_proc.dat | 5 +++++
2 files changed, 15 insertions(+)
diff --git a/src/backend/commands/extension.c b/src/backend/commands/extension.c
index 180f4af9be3..fcac8226c53 100644
--- a/src/backend/commands/extension.c
+++ b/src/backend/commands/extension.c
@@ -3863,3 +3863,13 @@ new_ExtensionControlFile(const char *extname)
return control;
}
+
+Datum
+pg_creating_extension(PG_FUNCTION_ARGS)
+{
+ if (creating_extension)
+ {
+ PG_RETURN_OID(CurrentExtensionObject);
+ }
+ PG_RETURN_NULL();
+}
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 62beb71da28..c75cc39f5fe 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -10727,6 +10727,11 @@
proname => 'pg_extension_config_dump', provolatile => 'v', proparallel => 'u',
prorettype => 'void', proargtypes => 'regclass text',
prosrc => 'pg_extension_config_dump' },
+{ oid => '3814',
+ descr => 'determine if an extension is currently being created',
+ proname => 'pg_creating_extension', provolatile => 'v', proparallel => 'u',
+ prorettype => 'oid', proargtypes => '',
+ prosrc => 'pg_creating_extension' },
# SQL-spec window functions
{ oid => '3100', descr => 'row number within partition',
--
2.43.2
On 19 Apr 2025, at 4:18 AM, Yurii Rashkovskii <yrashk@omnigres.com> wrote:
Hi,
I propose to introduce `pg_creating_extension()` function that would return the OID of the extension being currently created (or `null` if none is).
The core motivation for it is to be able to establish data provenance in tables created by extensions to be used in `pg_extension_config_dump` configuration. This way, even if a secondary extension inserts data, it can still be excluded from the dump by tracking data provenance in a column with a default. Something like
``` create table my_config ( --- ... extension_provenance oid default pg_creating_extension() ) ```This would allow for a generalized exclusion in pg_extension_config_dump.
I've attached a draft patch for this simple function. I am happy to finalize it with tests and documentation if there is a consensus on the shape.
--
Founder at Omnigres
https://omnigres.com <https://omnigres.com/><v1-0001-pg_creating_extension-to-inspect-if-an-extension-is-.patch>
Hi Yurii,
+1 from me.
I can see this being helpful, especially when dealing with shared tables or managing extension-specific data in configuration dumps.
On 19/4/2025 03:18, Yurii Rashkovskii wrote:
This would allow for a generalized exclusion in pg_extension_config_dump.
I've attached a draft patch for this simple function. I am happy to
finalize it with tests and documentation if there is a consensus on the
shape.
I must admit that I rarely use the pg_extension_config_dump feature.
Additionally, the term 'secondary extension' is not entirely clear to me.
To ensure we are on the same page, it would be helpful to see the
specific case you are referring to as a regression test or TAP test
included with the patch.
--
regards, Andrei Lepikhov