From: Jean-Luc Lachance <jllachan@nsd.ca>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Upgrading the backend's error-message infrastructure
Date: Thu, 13 Mar 2003 16:42:45 -0500
Message-ID: <3E70FB55.68CEDE4@nsd.ca> (raw)
References: <9168.1047588660@sss.pgh.pa.us>
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.
>
[...]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: jllachan@nsd.ca, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: Upgrading the backend's error-message infrastructure
In-Reply-To: <3E70FB55.68CEDE4@nsd.ca>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox