Re: pg_migrator to /contrib in a later 9.0 beta

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_migrator to /contrib in a later 9.0 beta
Дата
Msg-id 201005021430.o42EU0x10855@momjian.us
обсуждение исходный текст
Ответ на Re: pg_migrator to /contrib in a later 9.0 beta  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas wrote:
> On Sat, May 1, 2010 at 5:46 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> > Agreed, we're not holding up 9.0 for it. ?I think the main bit of work
> >> > that would be needed to put it into contrib would be to SGML-ize the
> >> > docs. ?Don't know if Bruce has got the time to get that done.
> >>
> >> Creating the SGML docs is trivial, especially compared to the 9.0
> >> release notes SGML. ?;-) ?It will take only an hour --- I am basically
> >> going to merge the README and the INSTALL file, remove mentions about
> >> migrating to < 9.0, and add SGML markup. ?I labored on README and the
> >> INSTALL files for a long time and can't figure out how to improve them.
> >
> > Oh, and I will remove the C code that was used to migrate _to_ pre-9.0
> > databases. ?People can use the pgfoundry version for such cases. I have
> > specifically not created a pgfoundry release of pg_migrator that
> > migrates to 9.0. ?(It worked for the 8.5 numbering.)
> 
> I wonder if this is just going to lead to us maintaining two versions
> of pg_migrator, which wouldn't be awesome.  I don't think it's going
> to be practical to retain all the migration code for every pair of
> versions forever, but I'm reluctant to start changing things just
> because we're sucking the thing into our main tree.  Especially things
> that sound suspiciously like features.

Tom's idea basically was that each version of pg_migrator would only
support it current major version as a _target_.  We would have to
backpatch fixes to pg_migrator to previous major versions, and to
pgfoundry if necessary.

However, there isn't much code churn in pg_migrator anymore (as there
was months before), so we should be OK.  We already do such backpatching
for all our other core code.

I can easily keep all the code in each version of pg_migrator.  However,
pg_dump only supports loads into the _target_ major version, just like
pg_migrator would do.

I am unclear on which direction to take, but both are easy for me.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: standbycheck was:(Re: [HACKERS] testing hot standby
Следующее
От: Tom Lane
Дата:
Сообщение: Re: TOAST code ignores freespace (was Tweak TOAST code)