Subject: Re: select_common_typmod
To: Heikki Linnakangas <hlinnaka@iki.fi>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <97df3af9-8b5e-fb7f-a029-3eb7e80d7af9@2ndquadrant.com>
 <3152222d-4792-d75b-46a8-de22ebb0de31@iki.fi>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <adf469d0-cbe2-1890-12c1-d5268d7b53ac@2ndquadrant.com>
Date: Tue, 27 Oct 2020 18:12:05 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <3152222d-4792-d75b-46a8-de22ebb0de31@iki.fi>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2020-10-26 10:05, Heikki Linnakangas wrote:
>> There might have been a tiny bug in transformValuesClause() because
>> while consolidating the typmods it does not take into account whether
>> the types are actually the same (as more correctly done in
>> transformSetOperationTree() and buildMergedJoinVar()).
> 
> Hmm, it seems so, but I could not come up with a test case to reach that
> codepath. I think you'd need to create two types in the same
> typcategory, but with different and incompatible typmod formats.

Yeah, something like that.

> The patch also adds typmod resolution for hypothetical ordered-set
> aggregate arguments. I couldn't come up with a test case that would
> tickle that codepath either, but it seems like a sensible change. You
> might want to mention it in the commit message though.

OK, committed with that.

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