Re: pgsql: Further code review for pg_lsn data type.
От | Andres Freund |
---|---|
Тема | Re: pgsql: Further code review for pg_lsn data type. |
Дата | |
Msg-id | 20140220151257.GS28858@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: Further code review for pg_lsn data type. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Further code review for pg_lsn data type.
|
Список | pgsql-committers |
On 2014-02-20 09:59:51 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > 6.3.1.3 Signed and unsigned integers, paragraph 3: > > "Otherwise, the new type is signed and the value cannot be represented > > in it; either the result is implementation-defined or an > > implementation-defined signal is raised." > > "Implementation-defined" is entirely different from "undefined". Yea, I don't think I talked about undefined behaviour in the context of this. The undefined behaviour bit was more about the aliasing and such. I *do* think it might be worth fixing that someday, but it's certainly nothing presssing. > I think you're making a problem out of nothing. We have considerably > more-real portability issues to worry about, like memory ordering. I don't think it's a huge problem, but it's pretty easy to avoid, so why not avoid it? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-committers по дате отправления: