Thread: 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