| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Greg Stark <stark(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Subject: | Re: pg_migrator and an 8.3-compatible tsvector data type |
| Date: | 2009-06-01 03:49:19 |
| Message-ID: | 27650.1243828159@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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.
(Which is not to say that pg_migrator isn't a hack; it surely is.
But it looks like the least painful approach available.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2009-06-01 03:49:51 | Re: Win32 link() function |
| Previous Message | Bruce Momjian | 2009-06-01 03:45:51 | Re: pg_migrator and an 8.3-compatible tsvector data type |