| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Subject: | Re: Add TG_* vars for FOR PORTION OF |
| Date: | 2026-09-06 13:10:14 |
| Message-ID: | CAN4CZFP4gyTjZQaS3kLqGMJKxiu0EGBZCngumtb45pXjKEBonQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello!
I have a generic design question: as I mentioned in [1], we also have
a similar situation outside FOR PORTION OF when a plain update moves a
record across partitions. Maybe we should have a detection logic that
can answer this question in a generic way, that could be also used by
every similar code in the future? Giving users simply the ability to
ask "Was this before insert trigger caused by an implicit insert?",
for example.
@@ -2453,6 +2453,7 @@ typedef struct ForPortionOfExpr
Oid withoutPortionProc; /* SRF proc for old_range - target_range */
ParseLoc location; /* token location, or -1 if unknown */
ParseLoc targetLocation; /* token location, or -1 if unknown */
+ char *range_name; /* Range name */
} ForPortionOfExpr;
Is this an (accidental) partial revert of 7090c696cc9?
+ Also set for the implicit <literal>INSERT</literal> statements to add
+ the <glossterm linkend="glossary-temporal-leftovers">temporal
+ leftovers</glossterm>.
This doesn't seem to work on partitioned tables to me. With a hash
partitioned setup, I see:
NOTICE: BEFORE UPDATE on ph0 : TG_PERIOD_NAME=valid_at
NOTICE: BEFORE DELETE on ph0 : TG_PERIOD_NAME=valid_at
NOTICE: BEFORE INSERT on ph3 : TG_PERIOD_NAME=<NULL>
NOTICE: AFTER INSERT on ph3 : TG_PERIOD_NAME=<NULL>
NOTICE: BEFORE INSERT on ph1 : TG_PERIOD_NAME=<NULL>
NOTICE: AFTER INSERT on ph1 : TG_PERIOD_NAME=<NULL>
NOTICE: BEFORE INSERT on ph2 : TG_PERIOD_NAME=<NULL>
NOTICE: AFTER DELETE on ph0 : TG_PERIOD_NAME=valid_at
NOTICE: AFTER INSERT on ph2 : TG_PERIOD_NAME=<NULL>
Or with cross-partition row movement:
NOTICE: BEFORE DELETE on pl1 : TG_PERIOD_NAME=valid_at
NOTICE: BEFORE INSERT on pl2 : TG_PERIOD_NAME=<NULL>
NOTICE: AFTER DELETE on pl1 : TG_PERIOD_NAME=valid_at
NOTICE: AFTER INSERT on pl2 : TG_PERIOD_NAME=<NULL>
+ <structfield>fp_leftoverstypcache</structfield> is the type
cache entry of the range column,
This seems to be NULL for BEFORE ROW triggers, as it is populated
after them? That should be at least mentioned.
+ END IF;
+ RETURN CASE WHEN 'TG_OP' = 'DELETE' THEN OLD ELSE NEW END;
This will always evaluate to false, it compares 'TG_OP' as string
One more documentation / possibly release note question: should we
mention that some additional names are now 'reserved'? If there is a
preexisting plpgsql function using a variable named tg_period_name, it
will start failing with this patch applied. Even if that is unlikely,
it seems like a good idea to mention this change somewhere.
[1]: https://postgr.es/m/CA%2BrenyV1Y4hzdG%3DbtbUc69%3DcCxOGBFqSGJ5CrOrB15YH6PXdrg%40mail.gmail.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rui Zhao | 2026-09-06 15:04:12 | Re: Improving display of octal GUCs |
| Previous Message | Andrey Borodin | 2026-09-06 12:49:45 | Re: Avoid streaming zero-filled WAL switch padding |