Re: Removing pg_migrator limitations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removing pg_migrator limitations
Date
Msg-id 15594.1261186280@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removing pg_migrator limitations  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Removing pg_migrator limitations  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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;
voidset_next_pg_class_oid(Oid oid){    next_pg_class_oid = oid;}

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Removing pg_migrator limitations
Next
From: Tom Lane
Date:
Subject: Re: Removing pg_migrator limitations