On Jun 7, 2009, at 12:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Robert Haas <robertmh...@gmail.com> writes:
I did know that EDB had been using the tool for a while, but I admit
I'm not familiar with the whole history. I had the impression that
we'd gotten a lot more serious about really making this rock solid
since Bruce took it in February. But maybe that's not the case?
I don't actually know the EDB end of the history either; maybe someone
can educate us about that. But it's true that the core developers,
at least, weren't taking it seriously until this year. That's because
it really can only handle catalog changes, not changes to the contents
of user tables; and it's been quite a long time since we've had a
release where we didn't change tuple header layout or packing rules or
something that made it a nonstarter. It wasn't clear till early this
year that 8.3->8.4 would be a cycle where pg_migrator had a chance of
being useful in production ... so we got serious about it.
OK, that's more or less what I thought, and what I intended to convey
upthread. As far as core Postgres is concerned this is a new feature,
and we haven't worked out all the kinks yet. As long as we set
expectations accordingly, I think that's OK. You mention CVEs for
these contrib issues, but will CVEs still be issued if we make clear
that this is experimental only? I would hope not, since that would
amount to a policy that any half-baked code anywhere on pgfoundry is
just as much our responsibility as core Postgres. Surely we're
allowed to say "good progress has been made here, but we harbor no
illusions that it's bullet-proof."
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
