Re: Removing pg_migrator limitations

Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > > ... The idea I had was to create a global structure:
> >
> > > struct pg_migrator_oids {
> > > Oid pg_type;
> > > Oid pg_type_array;
> > > ...
> > > }
> >
> > > This would initialize to zero as a global structure, and only
> > > pg_migrator server-side functions set it.
> >
> > I would prefer *not* to do that, as that makes the list of settable oids
> > far more public than I would like; also you are totally dependent on
> > pg_migrator and the backend to be in sync about the definition of that
> > struct, which is going to be problematic in alpha releases in
> > particular, since PG_VERSION isn't going to distinguish them.
> >
> > What I had in mind was more like
> >
> > static Oid next_pg_class_oid = InvalidOid;
> >
> > void
> > set_next_pg_class_oid(Oid oid)
> > {
> > next_pg_class_oid = oid;
> > }
>
> Good point about requiring a link to a symbol; a structure offset would
> not link to anything and would silently fail.
>
> Does exporting a function buy us anything vs. exporting a variable?
>
> > in each module that needs to be able to accept a next-oid setting,
> > and then the pg_migrator loadable module would expose SQL-callable
> > wrappers for these functions. That way, any inconsistency shows up as
> > a link error: function needed not present.
>
> I will work on a patch to accomplish this, and have pg_migrator link in
> the .so only if the new server is >= 8.5, which allows a single
> pg_migrator binary to work for migration to 8.4 and 8.5.

I have completed the attached patch which assigns oids for all pg_type
rows when pg_dump --binary-upgrade is used. This allows user-defined
arrays and composite types to be migrated cleanly. I tested a reload of
the regression database with --binary-upgrade and all the pg_type oids
were identical. The pg_migrator changes required to use this feature
are trivial.

The remaining issue is pg_enum oids. Because it will be difficult to
pass an arbitrary number of oids into the backend, the idea was to
assign each enum value separately. If we implement this TODO item:

Allow adding/renaming/removing enumerated values to an existing
enumerated data type

Particularly the "adding" part rather than the "renaming/removing" part,
pg_dump can create an enum type with one (or zero perhaps) enums, and
then use a pg_enum oid-setting function and then use ALTER TYPE ADD
ENUM to add each new value.

Comments?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +