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: 27688.1213803578@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

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

becomes just

ereport(ERROR,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
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

Responses

Browse pgsql-hackers by date

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