Re: Fix missing FORMAT when deparsing JSON_ARRAY(query)

On Thu, Jul 23, 2026 at 11:59 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Actually, since I'm sitting here at the AI workshop, I thought I'd
> try using Claude Code to generate a patch. Here's what it came up
> with, after only light steering by me (I told it to factor the patch
> this way, rather than making independent v19 and v20 patches).
> I would have used a much shorter test case, and some of the comments
> seem overly verbose too, but otherwise not bad.

I just took a brief look at this bug and concluded that the root cause
is that ForPortionOfExpr carries the range column in two redundant
forms: rangeVar and range_name. At deparse time, ruleutils.c prints
the range_name, which can be stale after RENAME.

And the patch Claude came up with here makes sense to me. The
rangeVar field already holds everything we need to print the
up-to-date name, so removing the range_name field makes sense.

A nit:
I'm not sure about this change in 0002:

tle = makeTargetEntry((Expr *) rangeTLEExpr, range_attno,
- forPortionOf->range_name, false);
+ pstrdup(NameStr(attr->attname)), false);

forPortionOf is a ForPortionOfClause, and range_name is a valid field.

> It was Claude's idea to have 2 patches at all: it thought we should
> avoid a post-beta2 catversion bump in v19. I might agree with it
> except I see catversion was bumped just a few days ago in v19,
> so there's no benefit in not doing so again.

Yeah, since catversion was already bumped post-beta2 in commit
372b8d1ad, I see no reason why we can't bump it again here.

- Richard