Tom Lane writes:
Hmm. I can't see any advantage to these over assigning our own codes;
ours would have at least *some* mnemonic value, rather than being chosen
completely at random ...
One advantage is that interfaces that are required to use these constants
would not need an internal
Tom Lane writes:
M Message --- the string is the primary error message (localized).
D Detail --- secondary error message, carrying more detail about
the problem (localized).
H Hint --- a suggestion what to do about the error (localized).
Client interfaces for the most part
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
MMessage --- the string is the primary error message (localized).
DDetail --- secondary error message, carrying more detail about
the problem (localized).
HHint --- a suggestion what to do about the error (localized).
Tom Lane writes:
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
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
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?
There's a possible solution: SQL99 part 3 defines numerical codes for
each of these
Tom Lane writes:
Error and Notice (maybe also Notify?) msgs will have this structure:
E
x string \0
x string \0
x string \0
\0
where the x's are single-character field identifiers.
I think we need more flexible field tags. The SQL standards has
provisions
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
where the x's are single-character field identifiers.
I think we need more flexible field tags. The SQL standards has
provisions for more fields accompanying error messages, such as the name
of the affected table.
Well, we can
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
Jean-Luc Lachance [EMAIL PROTECTED] writes:
Why trade 5 characters for a 4 byte integer -- a saving of 1 byte?
It's more than that: in one case you have something on the order of
a load immediate instruction, whereas in the other case the code
is like load pointer to global string, plus you need
