Re: Cleaning up historical portability baggage
От | Andres Freund |
---|---|
Тема | Re: Cleaning up historical portability baggage |
Дата | |
Msg-id | 20220712173352.trdeq66asbv6vf2q@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Cleaning up historical portability baggage (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Cleaning up historical portability baggage
|
Список | pgsql-hackers |
Hi, On 2022-07-12 08:01:40 -0400, Robert Haas wrote: > On Mon, Jul 11, 2022 at 9:11 PM Thomas Munro <thomas.munro@gmail.com> wrote: > > Hmm, but that's not what we're doing in general. For example, on > > Windows we're redirecting open() to a replacement function of our own, > > we're not using "pg_open()" in our code. That's not an example based > > on AC_REPLACE_FUNCS, but there are plenty of those too. Isn't this > > quite well established? > > Yes. I just don't care for it. > > Sounds like I'm in the minority, though. I agree with you, at least largely. Redefining functions, be it by linking in something or by redefining function names via macros, is a mess. There's places where we then have to undefine some of these things to be able to include external headers etc. Some functions are only replaced in backends, others in frontend too. It makes it hard to know what exactly the assumed set of platform primitives is. Etc. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: