From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: select_common_typmod |
Date: | 2020-10-26 09:05:11 |
Message-ID: | 3152222d-4792-d75b-46a8-de22ebb0de31@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2020-10-26 09:28:59 | Re: POC: GROUP BY optimization |
Previous Message | Dmitry Dolgov | 2020-10-26 08:57:21 | Re: POC: GROUP BY optimization |