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 01:37:53
Message-ID: 11916.1520127473@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:
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-03-04 01:46:17 Re: [HACKERS] plpgsql - additional extra checks
Previous Message Andres Freund 2018-03-04 01:13:25 Re: 2018-03 Commitfest Summary (Andres #1)