Re: pg_migrator and an 8.3-compatible tsvector data type

Greg Stark wrote:
> On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Sun, May 31, 2009 at 11:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> "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.
>
> Keep in mind that you have catalogs in all the databases, and even in
> standalone mode you need those catalogs to find the, er, catalogs.
> There's a reason bootstrap mode is so limited and even then it needs
> some of the catalogs to already be in place.
>
> >> (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.
>
> Well I think all we need for that is to have pg_migrator provide the
> old output function wrapped up in a migrate_foo() C function.

Yep, it is just a matter of using a custom function call rather than a
cast.

--
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. +