From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-docs <pgsql-docs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Table rewrite supporting functions for event triggers |
Date: | 2024-09-12 03:17:28 |
Message-ID: | ZuJdSA9U5OmgagbS@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Wed, Sep 11, 2024 at 10:14:27AM -0400, Greg Sabino Mullane wrote:
> I dunno - so would we smush them together and return something like:
>
> "ALTER_PERSISTENCE and COLUMN_REWRITE"
If multiple are set, let's just make it text[], then.
> That would be a step backwards for anyone possibly using that integer
> programatically to (for example) give a pretty user-facing message about
> why the event was triggered.
I don't know either how much people are relying on these numbers in
applications. If this is like what we do in the regression tests and
print it in notice messages within a PL/pgSQL function, that's not
going to matter.
Or just have a separate function..
Do you have a comment about mentioning the variables or the header in
the docs for the stable branches? I'm aware that this is a rare
practice, but so is this function's design. My argument is
greppability between the code and the docs, mainly, to not miss an
update of the docs if more reasons are added. That would be unlikely,
but a backpatch of a reason is not impossible ABI-wise.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2024-09-12 12:52:00 | Re: Table rewrite supporting functions for event triggers |
Previous Message | PG Doc comments form | 2024-09-11 23:26:50 | Add mention to related system catalog functions on Tablespaces documentation pages. |