Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
| От | Masahiko Sawada |
|---|---|
| Тема | Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation |
| Дата | |
| Msg-id | CAD21AoDWreYF=U1KL6z-WROLfDL7yajaw2XXCcv3MME=Z5o5pQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Tue, Oct 1, 2024 at 8:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Noah Misch <noah@leadboat.com> writes: > > On Tue, Oct 01, 2024 at 11:55:48AM -0700, Masahiko Sawada wrote: > >> Considering that the population of database cluster signedness will > >> converge to signedness=true in the future, we can consider using > >> -fsigned-char to prevent similar problems for the future. We need to > >> think about possible side-effects as well, though. > > > It's good to think about -fsigned-char. While I find it tempting, several > > things would need to hold for us to benefit from it: > > > - Every supported compiler has to offer it or an equivalent. > > - The non-compiler parts of every supported C implementation need to > > cooperate. For example, CHAR_MIN must change in response to the flag. See > > the first comment in cash_in(). > > - Libraries we depend on can't do anything incompatible with it. > > > Given that, I would lean toward not using -fsigned-char. It's unlikely all > > three things will hold. Even if they do, the benefit is not large. > > I am very, very strongly against deciding that Postgres will only > support one setting of char signedness. It's a step on the way to > hardware monoculture, and we know where that eventually leads. > (In other words, I categorically reject Sawada-san's assertion > that signed chars will become universal. I'd reject the opposite > assertion as well.) Thank you for pointing this out. I agree with both of you. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: