> On May 9, 2019, at 7:14 PM, Bruce Momjian wrote:
>
> On Wed, May 8, 2019 at 10:07:23PM +, Nasby, Jim wrote:
>> I don’t recall why pg_upgrade wants to control OIDs… don’t we
>> re-create all catalog entries for user objects from scratch?
>
> The C comment at top of pg_upgrade.c explains w
On Wed, May 8, 2019 at 10:07:23PM +, Nasby, Jim wrote:
> I don’t recall why pg_upgrade wants to control OIDs… don’t we
> re-create all catalog entries for user objects from scratch?
The C comment at top of pg_upgrade.c explains why some oids must be preserved:
https://git.postgresql
"Nasby, Jim" writes:
> The problem is that pg_dump --binary-upgrade intentionally does not
> simply issue a `CREATE EXTENSION` command the way a normal dump does, so
> that it can control the OIDs that are assigned to objects[1].
That's not the only reason. The original concerns were about not
b
pgTap has a view that references pg_proc; to support introspection of functions
and aggregates. That view references proisagg in versions < 11, and prokind in
11+. pgtap's make process understands how to handle this; modifying the
creation scripts as necessary. It actually has to do this for sev
