Bruce Momjian <bruce@momjian.us> writes:
> What I think you actually can do is to run pg_upgrade with a user that
> is not the install user in either cluster, as long as the oids match. I
> am afraid any more specific message could technically be wrong in some
> rare cases.
I think you missed my point. I'm suggesting actually restricting what
pg_upgrade will accept, so that the error conditions become simpler to
understand.
Furthermore, if your description of the restrictions is accurate, then
restricting to "the user must be the bootstrap superuser in both clusters"
is actually not an extra restriction. You said:
> o only one user can be defined in the new cluster (most likely the
> install user)
If there is only one user in the new cluster, it *is* the bootstrap
superuser, because that user cannot be deleted.
> o the oids of the two users must be the same (likely the install user
> on the old cluster as well)
If the OIDs are the same, then the old-cluster user is also the bootstrap
superuser, because the bootstrap superuser's hard-wired OID is 10. QED.
So I think you should get rid of the existing error check and simplify it
to "user must be bootstrap superuser (ie, OID 10) in both clusters".
The existing approach adds only confusion, not flexibility.
> What I think you actually can do is to run pg_upgrade with a user that
> is not the install user in either cluster, as long as the oids match.
I don't think you actually can, and if you could, I frankly would not
trust the results.
regards, tom lane
