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-04T01:37:53Z
Lists: pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: > Here is v2 of the fix. It does handle all the convert_to_scalar calls > for various data types, just like the numeric one did in v1 with the > exception of bytea. Pushed with some adjustments. > The bytea case is fixed by checking that the boundary values are > varlenas. This seems better than checking for BYTEAOID explicitly, which > would fail for custom varlena-based types. At first I've been thinking > there might be issues when the data types has mismatching ordering, but > I don't think the patch makes it any worse. I didn't like this one bit. It's unlike all the other cases, which accept only specific type OIDs, and there's no good reason to assume that a bytea-vs-something-else comparison operator would have bytea-like semantics. So I think it's better to punt, pending the invention of an API to let the operator supply its own convert_to_scalar logic. > I've also added a bunch of regression tests, checking each case. The > bytea test it should cause segfault on master, of course. I was kind of underwhelmed with these test cases, too, so I didn't commit them. But they were good for proving that the bytea bug wasn't hypothetical :-) 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