On Tue, Aug 2, 2011 at 8:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Yes. >> 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. Works for me. Just to confirm, that means we'd also change GEQO to use pg_erand48(). > 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... Good grief. It's hard to imagine a more user-hostile attitude than the one taken there. I did run into that precise issue, but managed to stumble on what is apparently the officially sanctioned method of working around it - viz, zeroing the state array. However, that bug report is a pretty compelling argument for the position that expecting any of the GNU blah_r() functions to behave halfway sanely or be properly documented is a pipe dream. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
