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