Re: updates for handling optional argument in system functions

Hi Mark,

I should have been clearer about points 1 and 2 in my last mail:

> 1. Every existing call form behaves the same as before.
>
> 2. pg_upgrade from an unpatched cluster works for views over these
> functions: afterwards the view trees reference pg_proc OIDs
> 2504/2505/2506 instead of 1573/1640/1641, and the views return the
> same rows as before the upgrade.

Those were confirmations that existing calls and views still work.
For the ACL failure later in point 2, I should have stated whether I
thought it needed special handling.

> Do I understand correctly that this is going to be considered an
> unusual and rare occurrence? That we will expect the user to manually
> handle the privileges instead of having pg_upgrade recognize that.

Yes, I think manual handling is reasonable here. I manually restored
the default privileges on pg_get_ruledef(oid) in the old cluster, then
reran pg_upgrade to v10. The upgrade completed.

> Am I misunderstanding?

I meant this as a reminder for developers, especially C extension
authors, when updating their code for the new major version. I'm not
asking you to preserve compatibility with the old C calls.

The macro changes will be caught when rebuilding, but an unchanged
DirectFunctionCall2(pg_get_expr, ...) still compiles with v10 headers;
I checked with -Werror. It needs the explicit third argument, just as
decompile_conbin() now passes BoolGetDatum(false) in
DirectFunctionCall3(). Recompiling alone doesn't fix that call.

I rebuilt and retested v10. LGTM.

One small comment remains: pg_get_indexdef() still says "In the extended
version, there is a colno argument as well as pretty bool." There is
only one version now, so that sentence could describe the arguments
without the "extended version" distinction.

Regards,
Rui