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

Ewan Young <kdbase.hack@gmail.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