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
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
>
> 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
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
14 matches
Mail list logo
