From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] user-defined numeric data types triggering ERROR:
 unsupported type
In-reply-to: <a105b486-b94d-8335-5a91-160e0b0d264b@2ndquadrant.com>
References: <b68441b6-d18f-13ab-b43b-9a72188a4e02@2ndquadrant.com>
 <9389.1506003842@sss.pgh.pa.us>
 <4b444362-4240-49e0-3523-724e5932b060@2ndquadrant.com>
 <24767.1506180446@sss.pgh.pa.us>
 <d526eb53-dbd6-d414-8e5d-21e644ce4549@2ndquadrant.com>
 <14597.1520038563@sss.pgh.pa.us>
 <42f4e37e-f923-6ea9-4172-cdec5a8c2d25@2ndquadrant.com>
 <b5cede7b-354b-83e6-ab1f-7a1bf8a232fa@2ndquadrant.com>
 <11916.1520127473@sss.pgh.pa.us>
 <82f29126-df5a-d4bc-f5b5-47233e29aaa6@2ndquadrant.com>
 <15879.1520182782@sss.pgh.pa.us>
 <07b0dcd6-45f7-a2d3-99c6-115490b2cc98@2ndquadrant.com>
 <25629.1520192235@sss.pgh.pa.us>
 <a105b486-b94d-8335-5a91-160e0b0d264b@2ndquadrant.com>
Comments: In-reply-to Tomas Vondra <tomas.vondra@2ndquadrant.com>
	message dated "Sun, 04 Mar 2018 21:17:50 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29011.1520196416.1@sss.pgh.pa.us>
Date: Sun, 04 Mar 2018 15:46:56 -0500
Message-ID: <29012.1520196416@sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On 03/04/2018 08:37 PM, Tom Lane wrote:
>> 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.

> I don't follow. How would adding new custom types break the checks? If
> someone adds a new type along with operators for comparing it with the
> built-in types (supported by convert_to_scalar), then surely it would
> hit a code path tested by those tests.

Well, I think the existing bytea bug is a counterexample to that.  If
someone were to repeat that mistake with, say, UUID, these tests would not
catch it, because none of them would exercise UUID-vs-something-else.
For that matter, your statement is false on its face, because even if
somebody tried to add say uuid-versus-int8, these tests would not catch
lack of support for that in convert_to_scalar unless the specific case of
uuid-versus-int8 were added to the tests.

> So perhaps the best thing we can do is documenting this in the comment
> before convert_to_scalar?

I already updated the comment inside it ...

			regards, tom lane