Subject: Re: [HACKERS] user-defined numeric data types triggering ERROR:
 unsupported type
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
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>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <07b0dcd6-45f7-a2d3-99c6-115490b2cc98@2ndquadrant.com>
Date: Sun, 4 Mar 2018 19:49:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <15879.1520182782@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 03/04/2018 05:59 PM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> On 03/04/2018 02:37 AM, Tom Lane wrote:
>>> 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 :-)
> 
>> Underwhelmed in what sense? Should the tests be constructed in some
>> other way, or do you think it's something that doesn't need the tests?
> 
> The tests seemed pretty ugly, and I don't think they were doing much to
> improve test coverage by adding all those bogus operators.  Now, a look at
> https://coverage.postgresql.org/src/backend/utils/adt/selfuncs.c.gcov.html
> says that our test coverage for convert_to_scalar stinks, but we could
> (and probably should) improve that just by testing extant operators.
> 

Hmmm, OK. I admit the tests weren't a work of art, but I didn't consider
them particularly ugly either. But that's a matter of taste, I guess.

Using existing operators was the first thing I considered, of course,
but to exercise this part of the code you need an operator that:

1) exercises uses ineq_histogram_selectivity (so either scalarineqsel or
prefix_selectivity)

2) has oprright != oprleft

3) either oprright or oprleft is unsupported by convert_to_scalar

I don't think we have such operator (built-in or in regression tests).
At least I haven't found one, and this was the simplest case that I've
been able to come up with. But maybe you had another idea.

> A concrete argument for not creating those operators is that they pose a
> risk of breaking concurrently-running tests by capturing inexact argument
> matches (cf CVE-2018-1058).  There are ways to get around that, eg run
> the whole test inside a transaction we never commit; but I don't really
> think we need the complication.
> 

I don't think the risk of breaking other tests is very high - the
operators were sufficiently "bogus" to make it unlikely, I think. But
it's simple to mitigate that by either running the test in a
transaction, dropping the operators at the end of the test, or just
using some sufficiently unique operator name (and not '>').

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.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services