Обсуждение: Testing the other tsearch dictionaries
I was a bit unhappy to realize just now that the patch Heikki sent in, and I reviewed and applied, actually broke dict_synonym. (Modifying a string tends to modify the result of strlen() ...) While we can't cover *everything* in the regression tests, it now seems like a bad idea that the tsearch.sql test has no coverage at all for the ispell, synonym, or thesaurus templates. The difficulty in testing these is that they require configuration files, which the regression tests really can't install. (If the configuration were all inside the database it wouldn't be such a problem, but that's a lost cause for 8.3...) For synonym and thesaurus, we could rename the sample files that are currently installed so that they'd be actually accessible as config files, that is something likesynonym.syn.sample => synonym-sample.synthesaurus.ths.sample => thesaurus-sample.ths and then perform tests using those. (This would also provide test coverage for CREATE TEXT SEARCH DICTIONARY etc, which wouldn't be a bad thing.) The downsides I can see of this are (1) it'd expose some rather useless test files as things that people could create dictionaries with, and (2) someone might then alter the sample file and thereby cause regression tests to fail on their installation. Neither of these seem terribly bad, but has anyone got an objection or better idea? Also, we don't currently have any sample config files for ispell; but this is surely a loser from a documentation standpoint as well as a testing standpoint, so I think we should provide some. regards, tom lane
Tom Lane wrote: > I was a bit unhappy to realize just now that the patch Heikki sent in, > and I reviewed and applied, actually broke dict_synonym. (Modifying a > string tends to modify the result of strlen() ...) While we can't > cover *everything* in the regression tests, it now seems like a bad > idea that the tsearch.sql test has no coverage at all for the ispell, > synonym, or thesaurus templates. Agreed, we really need regression tests for this stuff one way or other. It's a lot of code, not very well tested, and likely to be modified in the future as well. > The difficulty in testing these is that they require configuration > files, which the regression tests really can't install. (If the > configuration were all inside the database it wouldn't be such a > problem, but that's a lost cause for 8.3...) How about putting the sample config files in contrib/tsearch, and copying them at "make install"? We have the capability to install contrib modules at the beginning of regression tests, right? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
"Heikki Linnakangas" <heikki@enterprisedb.com> writes: > Tom Lane wrote: >> The difficulty in testing these is that they require configuration >> files, which the regression tests really can't install. (If the >> configuration were all inside the database it wouldn't be such a >> problem, but that's a lost cause for 8.3...) > How about putting the sample config files in contrib/tsearch, and > copying them at "make install"? We have the capability to install > contrib modules at the beginning of regression tests, right? No, we have the ability to run a contrib module that's already been installed. pg_regress cannot assume it has write privileges on $SHAREDIR --- consider the "make installcheck" case. regards, tom lane
Tom Lane wrote: > > No, we have the ability to run a contrib module that's already been > installed. pg_regress cannot assume it has write privileges on > $SHAREDIR --- consider the "make installcheck" case. > > > How big are these files? If small, is there a reason we can't actually ship them as samples? cheers andrew
Andrew Dunstan wrote: > Tom Lane wrote: >> >> No, we have the ability to run a contrib module that's already been >> installed. pg_regress cannot assume it has write privileges on >> $SHAREDIR --- consider the "make installcheck" case. > > How big are these files? If small, is there a reason we can't actually > ship them as samples? We do. Currently they have a ".sample" suffix. Admin is supposed to make a copy of them, modify, and save with the right suffix. Tom suggested that we rename them so that they can be used directly. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com