From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-docs <pgsql-docs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Table rewrite supporting functions for event triggers |
Date: | 2024-09-11 06:00:31 |
Message-ID: | ZuEx_09-ohYExkJG@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Tue, Sep 03, 2024 at 09:34:02PM +0200, Laurenz Albe wrote:
> On Tue, 2024-09-03 at 11:54 -0400, Greg Sabino Mullane wrote:
>> How about something like this?
>
> This patch looks good to me.
- Returns a code explaining the reason(s) for rewriting. The exact
- meaning of the codes is release dependent.
+ Returns a code explaining the reason(s) for rewriting. The value is
+ a bitmap built from the following values: 1 (the table has changed
+ persistence), 2 (a column has changed a default value), 4 (a column
+ has a new data type), and 8 (the table access method has changed).
Agreed that the user experience with this function is poor and that
the documentation should be improved. Still, I am not sure that this
is optimal. On top of the values, how about adding the variable names
and also mention that these are defined in event_trigger.h?
Putting the documentation change aside for a bit, could it be better
to redesign this function and return a text value rather than an
integer? We could directly return the names, minus "AT_REWRITE_", for
instance.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-09-11 06:37:17 | Re: Undocumented optionality of handler_statements |
Previous Message | Daniel Gustafsson | 2024-09-10 13:02:52 | Re: Documentation improvement patch |