I wrote: > I think we should replace the whole mess with, say, uint32 for float and > UINT_MAX for infinity. That will be more portable, probably faster, and > it will work correctly up to substantially *larger* peak distances than > the existing code.
After studying the logic a bit more, I realized that the "finite" distances computed by the algorithm can actually never exceed u_size, which we're already constraining to be less than SHRT_MAX so that the adjacency arrays can be "short". So I made it use "short" storage for distances too, with SHRT_MAX as the infinity value. If we ever find a need to work with graphs exceeding 32K nodes, it will be trivial to s/short/int/g in this code. 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