public inbox for [email protected]
help / color / mirror / Atom feedRFC: logical publication via inheritance root?
4+ messages / 3 participants
[nested] [flat]
* RFC: logical publication via inheritance root?
@ 2022-12-09 18:21 Jacob Champion <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Jacob Champion @ 2022-12-09 18:21 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
Hi,
TImescale makes use of inheritance in its partitioning implementation,
so we can't make use of the publish_via_partition_root publication
option during logical replication. We don't guarantee that the exact
same partitions exist on both sides, so that's a major roadblock for
our implementing logical subscription support, and by the same token
it's not possible to replicate out to a "standard" table.
If we were to work on a corresponding publish_via_inheritance_root
option, is there a chance that it'd be accepted, or is there some
other technical reason preventing it? In addition to Timescale, it
seems like other installations using extensions like pg_partman could
potentially make use of this, during online migrations from the old
style of partitioning to the new.
Some inheritance hierarchies won't be "partitioned" hierarchies, of
course, but the user can simply not set that replication option for
those publications. (Alternatively, I can imagine a system where an
extension explicitly marks a table as having a different "publication
root", and then handling that marker with the existing replication
option. But that may be overengineering things.)
WDYT?
--Jacob
^ permalink raw reply [nested|flat] 4+ messages in thread
* [PATCH 2/2] make the output generally usable, not just for datum_to_json[b]
@ 2023-07-13 16:06 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Alvaro Herrera @ 2023-07-13 16:06 UTC (permalink / raw)
---
src/backend/utils/adt/jsonfuncs.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/src/backend/utils/adt/jsonfuncs.c b/src/backend/utils/adt/jsonfuncs.c
index 764d48505b..a4bfa5e404 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/adt/jsonfuncs.c
@@ -5705,16 +5705,10 @@ json_categorize_type(Oid typoid, bool is_jsonb,
*outfuncoid = InvalidOid;
- /*
- * We need to get the output function for everything except date and
- * timestamp types, booleans, array and composite types, json and jsonb,
- * and non-builtin types where there's a cast to json. In this last case
- * we return the oid of the cast function instead.
- */
-
switch (typoid)
{
case BOOLOID:
+ *outfuncoid = F_BOOLOUT;
*tcategory = JSONTYPE_BOOL;
break;
@@ -5729,26 +5723,27 @@ json_categorize_type(Oid typoid, bool is_jsonb,
break;
case DATEOID:
+ *outfuncoid = F_DATE_OUT;
*tcategory = JSONTYPE_DATE;
break;
case TIMESTAMPOID:
+ *outfuncoid = F_TIMESTAMP_OUT;
*tcategory = JSONTYPE_TIMESTAMP;
break;
case TIMESTAMPTZOID:
+ *outfuncoid = F_TIMESTAMPTZ_OUT;
*tcategory = JSONTYPE_TIMESTAMPTZ;
break;
case JSONOID:
- if (!is_jsonb)
- getTypeOutputInfo(typoid, outfuncoid, &typisvarlena);
+ getTypeOutputInfo(typoid, outfuncoid, &typisvarlena);
*tcategory = JSONTYPE_JSON;
break;
case JSONBOID:
- if (!is_jsonb)
- getTypeOutputInfo(typoid, outfuncoid, &typisvarlena);
+ getTypeOutputInfo(typoid, outfuncoid, &typisvarlena);
*tcategory = is_jsonb ? JSONTYPE_JSONB : JSONTYPE_JSON;
break;
@@ -5756,9 +5751,15 @@ json_categorize_type(Oid typoid, bool is_jsonb,
/* Check for arrays and composites */
if (OidIsValid(get_element_type(typoid)) || typoid == ANYARRAYOID
|| typoid == ANYCOMPATIBLEARRAYOID || typoid == RECORDARRAYOID)
+ {
+ *outfuncoid = F_ARRAY_OUT;
*tcategory = JSONTYPE_ARRAY;
+ }
else if (type_is_rowtype(typoid)) /* includes RECORDOID */
+ {
+ *outfuncoid = F_RECORD_OUT;
*tcategory = JSONTYPE_COMPOSITE;
+ }
else
{
/*
--
2.30.2
--gwvzdwvxkrbebefn--
^ permalink raw reply [nested|flat] 4+ messages in thread
* [PATCH 2/2] make the output generally usable, not just for datum_to_json[b]
@ 2023-07-13 16:06 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Alvaro Herrera @ 2023-07-13 16:06 UTC (permalink / raw)
---
src/backend/utils/adt/jsonfuncs.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/src/backend/utils/adt/jsonfuncs.c b/src/backend/utils/adt/jsonfuncs.c
index 764d48505b..a4bfa5e404 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/adt/jsonfuncs.c
@@ -5705,16 +5705,10 @@ json_categorize_type(Oid typoid, bool is_jsonb,
*outfuncoid = InvalidOid;
- /*
- * We need to get the output function for everything except date and
- * timestamp types, booleans, array and composite types, json and jsonb,
- * and non-builtin types where there's a cast to json. In this last case
- * we return the oid of the cast function instead.
- */
-
switch (typoid)
{
case BOOLOID:
+ *outfuncoid = F_BOOLOUT;
*tcategory = JSONTYPE_BOOL;
break;
@@ -5729,26 +5723,27 @@ json_categorize_type(Oid typoid, bool is_jsonb,
break;
case DATEOID:
+ *outfuncoid = F_DATE_OUT;
*tcategory = JSONTYPE_DATE;
break;
case TIMESTAMPOID:
+ *outfuncoid = F_TIMESTAMP_OUT;
*tcategory = JSONTYPE_TIMESTAMP;
break;
case TIMESTAMPTZOID:
+ *outfuncoid = F_TIMESTAMPTZ_OUT;
*tcategory = JSONTYPE_TIMESTAMPTZ;
break;
case JSONOID:
- if (!is_jsonb)
- getTypeOutputInfo(typoid, outfuncoid, &typisvarlena);
+ getTypeOutputInfo(typoid, outfuncoid, &typisvarlena);
*tcategory = JSONTYPE_JSON;
break;
case JSONBOID:
- if (!is_jsonb)
- getTypeOutputInfo(typoid, outfuncoid, &typisvarlena);
+ getTypeOutputInfo(typoid, outfuncoid, &typisvarlena);
*tcategory = is_jsonb ? JSONTYPE_JSONB : JSONTYPE_JSON;
break;
@@ -5756,9 +5751,15 @@ json_categorize_type(Oid typoid, bool is_jsonb,
/* Check for arrays and composites */
if (OidIsValid(get_element_type(typoid)) || typoid == ANYARRAYOID
|| typoid == ANYCOMPATIBLEARRAYOID || typoid == RECORDARRAYOID)
+ {
+ *outfuncoid = F_ARRAY_OUT;
*tcategory = JSONTYPE_ARRAY;
+ }
else if (type_is_rowtype(typoid)) /* includes RECORDOID */
+ {
+ *outfuncoid = F_RECORD_OUT;
*tcategory = JSONTYPE_COMPOSITE;
+ }
else
{
/*
--
2.30.2
--gwvzdwvxkrbebefn--
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
@ 2024-06-06 23:20 Jeff Davis <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Jeff Davis @ 2024-06-06 23:20 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; Isaac Morland <[email protected]>; +Cc: Ashutosh Sharma <[email protected]>; Ashutosh Bapat <[email protected]>; pgsql-hackers
On Fri, 2024-06-07 at 00:19 +0200, Jelte Fennema-Nio wrote:
> Even by default making the search_path "pg_catalog, pg_temp" for
> functions created by extensions would be very useful.
Right now there's no syntax to override that. We'd need something to
say "get the search_path from the session".
Regards,
Jeff Davis
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-06-06 23:20 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-12-09 18:21 RFC: logical publication via inheritance root? Jacob Champion <[email protected]>
2023-07-13 16:06 [PATCH 2/2] make the output generally usable, not just for datum_to_json[b] Alvaro Herrera <[email protected]>
2023-07-13 16:06 [PATCH 2/2] make the output generally usable, not just for datum_to_json[b] Alvaro Herrera <[email protected]>
2024-06-06 23:20 Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions Jeff Davis <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox