Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
От | Michael Paquier |
---|---|
Тема | Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends |
Дата | |
Msg-id | ZX1rmhppwgaczYQ7@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
|
Список | pgsql-bugs |
On Tue, Dec 12, 2023 at 09:37:58AM -0500, Tom Lane wrote: > ... I doubt that a contrib module would solve the problem for people > who can't afford a rewrite. pg_upgrade requires that datatype OIDs > stay the same, which is something I don't believe a contrib module > could manage. We've run into that before if memory serves. Is it > time to do something about that? Perhaps we could allow extension > modules to use binary_upgrade_set_next_pg_type_oid, and then somehow > reserve the money and _money OIDs forever? You mean with an integration in binary dumps? I don't see why it would not work and this facility may prove to be useful for out-of-core extension, assuming that this can be made transparent based on some new .control properties on the upgrade cluster, I guess.. Now, I am not sure that we're making users a favor in keeping around a data type that's kind of obsolete these days, particularly when all of them basically require handling of fractional cents when doing serious calculations. That's a trap in disguise, even if tying data to a locale for the unit sounds appealing for some applications. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: