Robert Haas <robertmh...@gmail.com> writes: >> If you want erand48_r, best to provide that API, not kluge up some >> other functions.
> ...because erand48() is a GNU extension with a stupid API. I assume you mean erand48_r, there, because erand48 is pretty standard. > I don't > see much value in supporting that, on both counts. We're going to end > up with the built-in erand48_r() on precisely those systems that use > glibc, and our own everywhere else. For the 25 SLOCs it's going cost > us, I'd rather use the same code everywhere. Maybe. But if that's the approach we want to use, let's just call it pg_erand48 in the code, and dispense with the alias macros as well as all vestiges of configure support. BTW, as far as the original plan of using random_r is concerned, how did you manage to not run into this? http://sourceware.org/bugzilla/show_bug.cgi?id=3662 I just wasted half an hour on that stupidity in an unrelated context... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
