> pgsql@mohawksoft.com wrote:
>> The point is that this *is* silly, but I am at a loss to understand why
>> it
>> isn't a no-brainer to change. Why is there a fight over a trivial change
>> which will ensure that PostgreSQL aligns to the documented behavior of
>> "open()"
>
> (Why characterise this as a "fight", rather than a discussion? Perhaps
> it is because of the same combative, adversarial attitude you seem to
> bring to every discussion you're involved in on -hackers...)
I really don't intend to do that, and it does seem to happen a lot. I am
the first to admit I lack tact, but often times I view the decisions made
as rather arbitrary and lacking a larger perspective, but that is a rant I
don't want to get right now.
>
> Anyway, I agree, there's no point keeping it a short; I highly doubt
> this would actually be a problem, but we may as well change it to an int.
And this is my point. There are things that are "no brainers," and a few
times I have been completely dumbfounded as to the source of resistence.
Silently truncating the upper 2 bytes of data type declared as an "int" is
a bug. I can't believe anyone would defend it, but here it happens.
Maybe it is me. I know I'm stubborn and confrontational, personally I've
wished I could be different, but I'm 42 so I guess I'm not going to change
any time soon.
Regardless of the source, if you want code to be portable, you have to
take APIs at face value. Any assumptions you think you can make are by
definition wrong. Allow the API authors the space to handle what they need
to handle.
Assuming a specific behavior is dangerous. Is it currently a problem, most
likely not, but since there is no downside, why leave it lurking to bite
us?
