Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> 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;
>> }
> Does exporting a function buy us anything vs. exporting a variable?
Hmm, probably not. I generally like to avoid global variables, but
in this case it doesn't seem to buy us anything to do so. Actually,
you could just have the core code do
/* don't make this static, pg_migrator needs to set it */Oid next_pg_class_oid = InvalidOid;
and not even bother with an extern declaration in the backend header
files (AFAIK gcc won't complain about that). That would help keep the
variable private to just the one core module plus pg_migrator.
> 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.
I think you're just creating useless work for yourself by imagining that
pg_migrator is backend-version-independent. In fact, I was thinking
about proposing that we pull it in as a contrib module. Because so much
of what it does is tied to details of backend and pg_dump behavior, it's
just a pipe dream to think that developing it as a separate project is
helpful.
regards, tom lane