Peter Eisentraut 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 two places where
I was looking into adding new specific SQL:2008 error codes for invalid
LIMIT and OFFSET values (see attached patch), when I came across an
existing error code definition:
#define ERRCODE_INVALID_LIMIT_VALUE MAKE_SQLSTATE('2','2', '0','2','0')
This definition has been in our sources since err
On Tue, Jul 06, 2004 at 01:22:35PM -0400, Bruce Momjian wrote:
> 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 g
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
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 good way to have a current list
>
> 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.
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 m
-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 protoco
[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 variab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As promised, I've been looking over the error handling (especially
the archived discussions) and it's a real rat's nest. :) I'm not
sure where we should start, but just getting some error codes
enabled and out there would be a great start. The pro
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
spe
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
> 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
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 err
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 th
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
> no
[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
d
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.
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 e
18 matches
Mail list logo
