Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade project status

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade project status
Date: 2009-01-27 14:54:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andrew Dunstan wrote:
> Heikki Linnakangas wrote:
>> Andrew Dunstan wrote:
>>> Zdenek Kotala wrote:
>>>> 2)
>>>> is shell script for catalog conversion. It works for
>>>> 8.3->8.4 upgrade. It will be useful while we will not have better
>>>> solution. Disadvantage is that it is korn shell script. The idea is to
>>>> rewrite it in PERL which is more portable, but I'm not PERL expert and
>>>> currently there is no workable solution.
>>> I have had a very brief look at this. Translation to perl doesn't
>>> look difficult. I'll see what I can do during the next week or so.
>> We don't require perl for any other feature, do we? Seems like a
>> pretty onerous requireemnt for Windows in particular. We do use perl
>> in the build scripts, but that's only required if you want to compile
>> from source.
> Well, from that POV the only portable thing is to translate it into C.
> That's just a whole lot more work (remember initdb?). The perl port for
> Windows is easily installable, widely used and well regarded. It doesn't
> strike me as too high a price to pay for the ability to do upgrades, but
> I'll defer to more Windows-centric commenters.

Either way, there's no point to discuss that in detail until there
actually is a working implementation out there... perl will do fine
until then. Once we have that, we can discuss if doing it in C will be
worthwhile, or if we're just going to require perl for that one feature.

I have a hard time thinking that we'll have wasted a lot of time on
first doing a perl implementation if we have to rewrite it in C later.
The other way around would be a waste though. The amount of time spent
on the perl implementation I expect to be a *lot* less than the
combination of thinking up the *way* to do it in general and the C
implementation time.


In response to


pgsql-hackers by date

Next:From: Dave PageDate: 2009-01-27 14:56:13
Subject: Re: pg_upgrade project status
Previous:From: Tom LaneDate: 2009-01-27 14:54:00
Subject: Re: Index Scan cost expression

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group