On Fri, Jun 15, 2012 at 10:27:59PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > On Fri, Jun 15, 2012 at 04:15:57PM +0100, Daniele Varrazzo wrote: > >> pg_upgrade fails on missing FTS dictionaries requiring external files. > >> --check fails to detect the incompatibility. > > > Sure, we can test for that. What system column stores these file names? > > Trying to check that on the basis of the system catalog entries seems > quite hopeless. What's in the catalogs is essentially what appears > in the CREATE command, ie > > dictfile = 'italian_ispell', afffile = 'italian_ispell', stopwords = > 'italian_ispell' > > The dictionary template knows which of these options are file names and > which are not, and what filename extension to apply to each option that > is a file name; but you don't. > > The closest that I think pg_upgrade could reasonably come is to compare > the contents of the old and new installations' tsearch_data/ > directories, and complain about any files present in the former and not > the latter. However, that method seems fraught with opportunities for > false positives: in particular you might complain about some file that > was in the old installation but not actually referenced by any text > search catalog entry. > > In the end I'm not sure it's worth it. There are any number of ways > that the restore step can fail, and it's impossible for pg_upgrade > to pre-check for all of them.
Agreed. Not worth it. If it is reported again, we can document this requirement. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
