Re: select_common_typmod
От | Heikki Linnakangas |
---|---|
Тема | Re: select_common_typmod |
Дата | |
Msg-id | 3152222d-4792-d75b-46a8-de22ebb0de31@iki.fi обсуждение исходный текст |
Ответ на | select_common_typmod (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: select_common_typmod
|
Список | 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
В списке pgsql-hackers по дате отправления: