> >> My solution would be to use INT_MIN for all ports, which has the advantage
> >> that the above problematic comparison can be converted to !=,
> >> since no integer will be smaller than INT_MIN.
> > I agree. When I was looking at this code this morning, I was wondering
> > what INT_MIN was supposed to represent anyway, if NOSTART_ABSTIME is
> > INT_MIN + 1. I think someone messed this up between 4.2 and Postgres95.
> > Thomas, any objection to this plan?
> I went ahead and committed this change, since Thomas hasn't weighed in
> with an objection ...
Hmm. I've been seeing a lot of followup messages to threads I don't
recall getting. Presumably all related to a combination of getting
auto-unsubscribed to -hackers :(, traveling and getting mail on my
laptop, and converting service at home over to DSL.
Hopefully this will all settle down here in the next few days.
Is the original issue support for 0x10... as the smallest integer, as
opposed to -MAX_INT? As long as we continue to map the "reserved values"
to the upper and lower range of allowed values so they are unlikely to
appear under normal circumstances, the change should be OK.
- Thomas