Peter Eisentraut pete...@gmx.net writes:
What should we do here, if anything? Redefine
ERRCODE_INVALID_LIMIT_VALUE to the new SQL:2008 code?
If you're going to spell the errcode macros as suggested in the
patch, just remove ERRCODE_INVALID_LIMIT_VALUE.
Note that this patch misses at least
David Fetter wrote:
Kind people,
So far, I have found two places where one can find the SQLSTATE error
codes: a header file, and the errcodes-appendix doc. Those are
excellent places.
Did I miss how to get a list of them in SQL? If I missed it because
it isn't there, what would be a
Given the repeatedly-asked-for functionalities (like error codes)
for which the stopper has been the long-threatened protocol revision,
I'd think it might be boring, but would hardly be thankless. Heck, I'd
expect a few whoops of joy around the lists.
Yes. Error codes would be great.
[EMAIL PROTECTED] writes:
What about a variable that allowed the codes to be switched on so a
number is returned instead of a string? This would be off by default
so as not to break existing applications. Similarly, we can return
other information (FILE, LINE, etc.) with different
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The *last* thing we need is a half-baked stopgap solution that we'll
have to be backwards-compatible with forevermore. Fix it right or
don't do it at all, is MHO.
I agree.
There is still barely enough time to do the long-threatened protocol
On Tue, Mar 04, 2003 at 11:04:03PM -0500, Tom Lane wrote:
There is still barely enough time to do the long-threatened protocol
revision for 7.4, if we suck it up and get started on that now. I've
been avoiding the issue myself, because it seems generally boring and
thankless work, but maybe
Insisting on Andreas suggestion, why can't we just prefix all error message
strings with the SQLState code? So all error messages would have the format
CCSSS -
Where CCSSS is the standard SQLState code and the message text is a more
Bruce wrote:
Actual error code numbers/letters. I think the new elog levels will
help with this. We have to decide if we want error numbers, or some
pneumonic like NOATTR or CONSTVIOL. I suggest the latter.
Since there is an actual standard for error codes, I would strongly suggest
to
[EMAIL PROTECTED] (Neil Conway) writes:
Should every elog() have an error code?
I believe we decided that it'd be okay to use one or two codes defined
like internal error, corrupted data, etc for all the elogs that are
not-supposed-to-happen conditions. What error codes are really for is
On Wed, Jul 17, 2002 at 03:57:56PM -0400, Tom Lane wrote:
[EMAIL PROTECTED] (Neil Conway) writes:
Should every elog() have an error code?
I believe we decided that it'd be okay to use one or two codes defined
like internal error, corrupted data, etc for all the elogs that are
Neil, attached are three email messages dealing with error message
wording.
I like Tom's idea of coding only the messages that are common/user
errors and leaving the others with a catch-all code.
We now have more elog levels in 7.3, so it should be easier to classify
the messages.
I can see
Neil Conway writes:
I'd like to implement error codes. I think they would be pretty useful,
although there are a few difficulties in the implementation I'd like
to get some input on.
OK, allow me to pass on to you the accumulated wisdom on this topic. :-)
Should every elog() have an error
Should every elog() have an error code? I'm not sure -- there are many
elog() calls that will never been seen by the user, since the error
they represent will be caught before control reaches the elog (e.g.
parse errors, internal consistency checks, multiple elog(ERROR)
for the same user
13 matches
Mail list logo
