Bruce Momjian <br...@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;
}
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
