Tom, > However, I think the whole patch is pretty useless. That code is not > broken as it stands, and doesn't appear to really gain anything from > the proposed change. Why should we risk any portability questions > when the code isn't going to get either simpler or shorter?
This patch "clears the way" for the proceeding change (2/2). We use the new inline functions to implement the proper checks to see if the sigpipe-masking syscalls are needed. We also need disable_sigpipe to be called when it's not the start of a block, hence the separate type definition. Cheers, Jeremy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers