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
