Re: compile error of PostgreSQL 7.2 on FreeBSD-current
От | Tom Lane |
---|---|
Тема | Re: compile error of PostgreSQL 7.2 on FreeBSD-current |
Дата | |
Msg-id | 24933.1013193627@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | compile error of PostgreSQL 7.2 on FreeBSD-current (hiroyuki hanai <hanai@imgsrc.co.jp>) |
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: >> We can certainly move our header inclusion order around, but that is >> simply an application-level workaround for a broken system header. > I didn't think so. I always thought there were requirements in include > ordering. There are certain broken OSes that think it's okay to let applications deal with that, but they are certainly broken. What is an application supposed to do if two different implementations have conflicting requirements for header include order? Why should it be an application's responsibility to worry about it in the first place? I don't even know of any place where it could be documented that "<foo.h> requires <bar.h> to be included first" in the standard man page layout, because there isn't a man page per header file. And I'll definitely bet lunch that that FreeBSD developer didn't fix the man pages to say any such thing when he made that typedef change ;-) If all versions of Unix had identical system headers then this sort of thing wouldn't be a big deal, but since they don't, "each header can be included independently" is the only reasonable approach. We have a number of workarounds of this kind in Postgres already, and I don't doubt that this one will not be the last one. But that does not persuade me that system headers with this sort of problem are acceptable. In this case we have an opportunity to complain, and we should. regards, tom lane
В списке pgsql-hackers по дате отправления: