On Sun, May 31, 2009 at 11:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> (At the risk of beating a dead horse, note if we were upgrading the
>> catalog tables directly via SQL, this type of scenario could be
>> handled cleanly without hacking pg_dump; I repeat my earlier critique
>> that the pg_migrator approach consigns us to a never-ending series of
>> pg_dump hacks, that or having it not work very well.)
>
> "Updating the catalog tables directly via SQL"? Good luck making that
> work. If you ever get it to work at all, it'll require a pile of hacks
> that will make pg_migrator look like paradise.
For clarity, I really mean "from a standalone backend", but ideally
I'd like it to be SQL.
> (Which is not to say that pg_migrator isn't a hack; it surely is.
> But it looks like the least painful approach available.)
Maybe. It seems that we don't have a good way of handling datatype
conversions. The approaches that have been proposed for tsvector
wouldn't work at all but for the fact that the new output function can
handle the old internal representation, which is not something that we
can guarantee in every case. And, even so, they leave the database in
a broken state until the post-migration scripts have been run. The
good news is that tsvector is not a datatype that everyone uses, and
those who do probably don't use it in every table, but what happens
when we want to change numeric incompatibly?
We really need to figure out an approach that lets us keep the old
datatypes around under a different name while making the original name
be the new version of the datatype. That way people can migrate and
be up, and deal with the need to rewrite their tables at a later time.Having the database come up quickly but in a
statewhere queries may
return wrong answers is a fairly poor excuse for in-place upgrade.
This is not to say that I don't appreciate the work Bruce is putting
into it, but I fear that without some more engineering it's just going
to be a hack used only by the desperate.
...Robert
