From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: Removing pg_migrator limitations |
Date: | 2009-12-20 18:07:12 |
Message-ID: | 200912201807.nBKI7CR19249@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-20 18:41:28 | LIKE INCLUDING COMMENTS code is a flight of fancy |
Previous Message | Tom Lane | 2009-12-20 17:52:32 | Re: Removing pg_migrator limitations |