Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type
Date: 2018-03-04 19:37:15
Message-ID: 25629.1520192235@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> FWIW I originally constructed the tests merely to verify that the fix
> actually fixes the issue, but I think we should add some tests to make
> sure it does not get broken in the future. It took quite a bit of time
> until someone even hit the issue, so a breakage may easily get unnoticed
> for a long time.

Oh, well, that was another problem I had with it: those tests do basically
nothing to ensure that we won't add another such problem in the future.
If somebody added support for a new type FOO, and forgot to ensure that
FOO-vs-not-FOO cases behaved sanely, these tests wouldn't catch it.
(At least, not unless the somebody added a FOO-vs-not-FOO case to these
tests, but it's hardly likely they'd do that if they hadn't considered
the possibility.)

I think actually having put in the coding patterns for what to do with
unsupported cases is our best defense against similar oversights in
future: probably people will copy those coding patterns. Maybe the bytea
precedent proves that some people will fail to think about it no matter
what, but I don't know what more we can do.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-04 19:46:22 Re: IndexJoin memory problem using spgist and boxes
Previous Message Tom Lane 2018-03-04 19:06:48 Re: PATCH: psql tab completion for SELECT