Message-ID: <3E70FB55.68CEDE4@nsd.ca>
Date: Thu, 13 Mar 2003 16:42:45 -0500
From: Jean-Luc Lachance <jllachan@nsd.ca>
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
Subject: Re: Upgrading the backend's error-message infrastructure
References: <9168.1047588660@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.
> 
[...]