Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type |
Дата | |
Msg-id | 11916.1520127473@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] user-defined numeric data types triggering ERROR:unsupported type (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] user-defined numeric data types triggering ERROR:unsupported type
|
Список | 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
В списке pgsql-hackers по дате отправления: