On 4/30/24 21:15, jian he wrote:
On Tue, Apr 30, 2024 at 4:35 PM David Steele <da...@pgmasters.net> wrote:
On 4/30/24 12:57, jian he wrote:
On Tue, Apr 30, 2024 at 10:26 AM David Steele <da...@pgmasters.net> wrote:
Since bb766cde cannot be readily applied to older commits in master I'm
unable to continue bisecting to find the ALTER TABLE behavioral change.
This seems to leave me with manual code inspection and there have been a
lot of changes in this area, so I'm hoping somebody will know why this
ALTER TABLE change happened before I start digging into it.
I just tested these two commits.
https://git.postgresql.org/cgit/postgresql.git/commit/?id=3da13a6257bc08b1d402c83feb2a35450f988365
https://git.postgresql.org/cgit/postgresql.git/commit/?id=b0e96f311985bceba79825214f8e43f65afa653a
i think it's related to the catalog not null commit.
it will alter table and add not null constraint internally (equivalent
to `alter table test alter id set not null`).
Yeah, looks like b0e96f31 was the culprit. Now that it has been reverted
in 6f8bb7c1 the pgAudit output is back to expected.
To be clear, I'm not saying this (now reverted) behavior was a bug, but
it was certainly a change in behavior so I thought it was worth pointing
out.
Anyway, I guess we'll see how this goes in the next dev cycle.
Thanks for helping me track that down!
Regards,
-David
