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. +