Re: Removing pg_migrator limitations - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Removing pg_migrator limitations
Date
Msg-id 200912201807.nBKI7CR19249@momjian.us
Whole thread Raw
In response to Re: Removing pg_migrator limitations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Removing pg_migrator limitations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> 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.

Yes, that was the idea.  We wouldn't expose the variable in other C
files unless necessary.

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

Well, I do think it will work for 8.3 to 8.4 ,and 8.4 to 8.5 --- I test
that regularly and I have not seen any failures in that regard.  If we
move it into /contrib, I will make sure fixes get backpatched.  FYI, a
typical test is:
   if (GET_MAJOR_VERSION(ctx.old.pg_version) <= 803 &&       GET_MAJOR_VERSION(ctx.new.pg_version) >= 804)

The biggest issue with versions is that it is hard for pg_migrator to
text changes in the server during major development so for example once
we add pg_dump support for system oids, it will then require CVS HEAD
for 8.5, but there are not that many people testing pg_migrator with
non-HEAD versions.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Removing pg_migrator limitations
Next
From: Tom Lane
Date:
Subject: LIKE INCLUDING COMMENTS code is a flight of fancy