Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-04T19:37:15Z
Lists: pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.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
Commits
-
Fix assorted issues in convert_to_scalar().
- e2108f58131f 9.6.9 landed
- bfade0e51ba9 10.4 landed
- ad3e3d731bae 9.5.13 landed
- 58d9acc18d38 11.0 landed
- 165fa27fe440 9.4.18 landed
- 0bea99bd929a 9.3.23 landed