Needs bisecting ...

I wonder what we got wrong.

(I agree that the "top level" bit was just wrong, but it's gone.)

That seems mighty unprincipled though.

In v12 (and probably earlier, didn't look) Table 9.45 defines @> as "Does the left JSON value contain the right JSON path/value entries at the top level?" [1].

But the only core-PG suspect is pg_stat_statements, and I can see that it does know that node type.

It's a lot simpler, and probably better performing, to use one key per cluster.

But the answer to that does not seem difficult to me: remember who issued the ALTER and see if they still have SET privilege at the time we activate a particular entry.

The reason this wasn't a bug before 86dc90056 is that any given plan tree could have only one target relation, so there was not anything else to suppress.

I'm quite certain that none of the last five are causing this, so you need to take it up with whoever provides "azure".

You could arbitrarily define months as 30 days and days as 24 hours, which is what some other interval functions do, and then the double result would be well-defined; but how useful is it really?

It seems quite pointless anyway considering that up to now, EvalPlanQualBegin has always zeroed the whole array.

We've done something similar before, and it seems a lot safer than having basically different logic in v16 than earlier branches.

I do not think that that GSS-API C symbol is a good precedent to follow.

(I went with "trans_abc" as the new table name, for consistency with some other nearby names.)

(Perhaps not the best place for such a thing, but somebody put it there.)

It's especially pointless when the main pgindent run for v16 is going to happen today (as soon as I get done clearing out my other queue items).

It's not entirely clear to me that the EPQ state it sets up is ever used; but if it is I think it is okay as I have it here, because it looks like those invocations always have just one result relation in the plan, so there aren't any "extra" result rels that need to be blocked.

I chose to replace the tuple_table field, because it was in a convenient spot and it seemed like the field least likely to have any outside code referencing it.

I don't believe that considering the union of the rels mentioned in any qual is a reasonable thing to do here.