Subject: Re: select_common_typmod
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <97df3af9-8b5e-fb7f-a029-3eb7e80d7af9@2ndquadrant.com>
From: Heikki Linnakangas <hlinnaka@iki.fi>
Message-ID: <3152222d-4792-d75b-46a8-de22ebb0de31@iki.fi>
Date: Mon, 26 Oct 2020 11:05:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <97df3af9-8b5e-fb7f-a029-3eb7e80d7af9@2ndquadrant.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 20/10/2020 11:58, Peter Eisentraut wrote:
> While working on another patch, I figured adding a
> select_common_typmod() to go along with select_common_type() and
> select_common_collation() would be handy.  Typmods were previously
> combined using hand-coded logic in several places, and not at all in
> other places.  The logic in select_common_typmod() isn't very exciting,
> but it makes the code more compact and readable in a few locations, and
> in the future we can perhaps do more complicated things if desired.

Makes sense.

> 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.

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.

- Heikki