I said: > I had missed the relevance of <condition information item name>, will > go look at it.
It looks to me like support of the SQL condition information items would require adding about two dozen optional fields to my spec for the Error protocol message, and the same number of optional errFOO(...) subroutines in the ereport() interface (only two or three of which would be likely to get invoked in any one ereport instance). This is a bit more than I'd been visualizing, but AFAICS the proposed mechanisms would work perfectly well with it. I won't bore the list with a detailed spec for the individual items --- they seem pretty obvious. Given that we now need order-of-thirty possible field types, do you feel uncomfortable with a single-byte field identifier in the FE/BE protocol? I'm still leaning that way on the grounds of compactness and programming simplicity, but I can see where someone might want to argue it won't do in the long run. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly