Skip site navigation (1) Skip section navigation (2)

Better error reporting for tsearch config file problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Better error reporting for tsearch config file problems
Date: 2008-06-18 15:39:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I'm not totally sure that bug #4253 reflects a problem in the user's
text search stopword files, but I'm suspicious.  If I deliberately
introduce an encoding error into italian.stop, I get

regression=# select to_tsvector('italian','prova');
ERROR:  invalid byte sequence for encoding "UTF8": 0xc30a
HINT:  This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".

This is fairly bad, because (a) it doesn't tell me where the problem is,
and (b) the HINT is outright misleading --- it will tend to make users
look to problems on the client side.

I am thinking that we could improve this dramatically by using the
"error context" feature.  I want to add a line like this:
	CONTEXT: line 42 of configuration file "/path/to/italian.stop"
and maybe even include the text of the line, when available (it'd be
unsafe to do that for encoding errors, for obvious reasons).  If the
context callback were active throughout the reading of each config
file, we could also get rid of the places where that info is supplied
in an ad-hoc manner, eg in dict_thesaurus.c

                 errmsg("unexpected delimiter at line %d of thesaurus file \"%s\"",
                        lineno, filename)));

becomes just

                 errmsg("unexpected delimiter")));

since the context callback will supply the rest.

This should be a simple, easily tested patch, and I am tempted to
propose back-patching it into 8.3, on the grounds that people need
help now --- by the time 8.4 is out they'll already have debugged
their config files.  However, altering these existing error messages
would create extra work for translators.  Any votes pro or con on that?

			regards, tom lane


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-06-18 16:01:35
Subject: Re: Reducing overhead for repeat de-TOASTing
Previous:From: Tom LaneDate: 2008-06-18 14:41:05
Subject: Re: Cleaning up cross-type arithmetic operators

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group