Re: Use ereport() instead of elog() for invalid weights in setweight()

Ewan Young <kdbase(dot)hack(at)gmail(dot)com> writes:
> I noticed that setweight() reports an internal error (SQLSTATE XX000)
> when the weight argument is not one of A/a, B/b, C/c, D/d, even though
> the weight comes directly from user input. The two-argument variant
> also prints the weight as a raw ASCII code, which is a bit unfriendly:

> =# SELECT setweight('cat:1'::tsvector, 'p');
> ERROR: unrecognized weight: 112

I agree that these ought to be ereport()s. However, I suspect that
the reason for printing bogus weights numerically was to avoid the
risk of generating encoding-incorrect strings if the given char
value has its high bit set. The existing code in tsvector_filter
is failing to consider that hazard.

I experimented with making the error messages print non-ASCII
characters differently, and soon decided that that added enough
complexity that we shouldn't have three copies of it. So the
attached proposed v2 also factors the code out into a new
function parse_weight (maybe a different name would be better?).

I'm unconvinced that we really need a regression test case for
this ...

regards, tom lane