Re: Removing pg_migrator limitations

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.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.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +