Why trade 5 characters for a 4 byte integer -- a saving of 1 byte?
Is this database designed for embedded applications where RAM is scarce?
:)
JLL
Tom Lane wrote:
[...]
> Error codes
> -----------
>
> The SQL spec defines a set of 5-character status codes (called SQLSTATE
> values). We'll use these as the language-independent identifiers for
> error conditions. There is code space reserved by the spec for
> implementation-defined error conditions, which we'll surely need.
>
> Per spec, each of the five characters in a SQLSTATE code must be a digit
> '0'-'9' or an upper-case Latin letter 'A'-'Z'. So it's possible to fit a
> SQLSTATE code into a 32-bit integer with some simple encoding conventions.
> I propose that we use such a representation in the backend; that is,
> instead of passing around strings like "1200D" we pass around integers
> formed like ((('1' - '0') << 6) + '2' - '0') << 6 ... This should save
> a useful amount of space per elog call site, and it won't obscure the code
> noticeably since all the common values will be represented as macro names
> anyway, something like
>
> #define ERRCODE_DIVISION_BY_ZERO MAKE_SQLSTATE('2','2', '0','1','2')
>
> We need to do some legwork to figure out what set of
> implementation-defined error codes we want. It might make sense to look
> and see what other DBMSes are using.
>
[...]
