Re: [HACKERS] Error codes for LIMIT and OFFSET
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 two places where new errcodes need to be listed (plerrcodes.h and the documentation appendix) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Error Codes
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 good way to have a current list available? You know, it would be cool to have the codes and descriptions in a global SQL table. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Error codes revisited
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. Regards, Christoph ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Error codes revisited
[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 variables. This should all be doable without a protocol change, as long as everything is returned as a string in a standard format. 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. 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 it's time to face up to it? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Error codes revisited
-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 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 it's time to face up to it? Definitely. Sure seems to be a lot involved, looking at the TODO page. Which brings up another question - if a protocol change doesn't warrant a bump to 8.0, what does? :) - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200303040645 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+ZC1LvJuQZxSWSsgRAkJLAKDUE54ZELrPc4ASqEtwUCk7CYJH/ACfZ7nQ bLRqMde1T9MDjzmejF+PBis= =Plww -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Error codes revisited
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 it's time to face up to it? 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. Ross ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] error codes
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 specific description. Note that the standard allows for implementation-defined codes, so we can have our own CC classes and all the SSS subclasses that we need. -- Fernando Nasser Red Hat - Toronto E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] error codes
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 adhere. The standardized codes are SQLSTATE a char(5) (well standardized for many classes of db errors). Also common, but not so standardized is SQLCODE a long (only a very few are standardized, like 100 = 'no data found'). And also sqlca. Also look at ecpg for sqlcode and sqlca. A Quote from dec rdb: o SQLCODE-This is the original SQL error handling mechanism. It is an integer value. SQLCODE differentiates among errors (negative numbers), warnings (positive numbers), succesful completion (0), and a special code of 100, which means no data. SQLCODE is a deprecated feature of the ANSI/ISO SQL standard. o SQLCA-This is an extension of the SQLCODE error handling mechanism. It contains other context information that supplements the SQLCODE value. SQLCA is not part of the ANSI/ISO SQL standard. However, many foreign databases such as DB2 and ORACLE RDBMS have defined proprietary semantics and syntax to implement it. o SQLSTATE-This is the error handling mechanism for the ANSI/ISO SQL standard. The SQLSTATE value is a character string that is associated with diagnostic information. To use the SQLSTATE status parameter, you must specify the SQL92 dialect and compile your module using DEC Rdb Version 6.0. Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] error codes
[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 distinguishing different kinds of user mistakes, and so that's where you need specificness. How should the backend code signal an error with an error number? Please read some of the archived discussions about this. All the points you mention have been brought up before. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] error codes
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 not-supposed-to-happen conditions. Ok, makes sense to me. How should the backend code signal an error with an error number? Please read some of the archived discussions about this. All the points you mention have been brought up before. Woops -- I wasn't aware that this had been discussed before, my apologies. I'm reading the archives now... Peter: are you planning to implement this? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] error codes
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 this job as several parts: --- Cleanup of error wording, removal of function names. See attached emails for possible standard. --- Reporting of file, line, function reporting using GUC/SET variable. For function names I see in the gcc 3.1 docs at http://gcc.gnu.org/onlinedocs/gcc-3.1/cpp/Standard-Predefined-Macros.html: C99 introduces __func__, and GCC has provided __FUNCTION__ for a long time. Both of these are strings containing the name of the current function (there are slight semantic differences; see the GCC manual). Neither of them is a macro; the preprocessor does not know the name of the current function. They tend to be useful in conjunction with __FILE__ and __LINE__, though. My gcc 2.95 (gcc version 2.95.2 19991024) supports both __FUNCTION__ and __func__, even though they are not documented in the info manual pages I have. I think we will need a configure.in test for this because it isn't a macro you can #ifdef. --- 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. --- I think we have plenty of time to get this done for 7.3. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 From [EMAIL PROTECTED] Fri Nov 30 12:14:19 2001 Return-path: [EMAIL PROTECTED] Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged)) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAUIEIR21802 for [EMAIL PROTECTED]; Fri, 30 Nov 2001 13:14:18 -0500 (EST) Received: from postgresql.org (postgresql.org [64.49.215.8]) by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fAUI6ER13094 for [EMAIL PROTECTED]; Fri, 30 Nov 2001 12:11:00 -0600 (CST) (envelope-from [EMAIL PROTECTED]) Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by postgresql.org (8.11.3/8.11.4) with ESMTP id fAUI58m98870 for [EMAIL PROTECTED]; Fri, 30 Nov 2001 13:05:08 -0500 (EST) (envelope-from [EMAIL PROTECTED]) Received: from [195.20.224.208] (helo=mrvdom01.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 169s27-00049P-00 for [EMAIL PROTECTED]; Fri, 30 Nov 2001 19:05:07 +0100 Received: from p3e9e6fa2.dip0.t-ipconnect.de ([62.158.111.162]) by mrvdom01.schlund.de with esmtp (Exim 2.12 #2) id 169s21-0001UP-00 for [EMAIL PROTECTED]; Fri, 30 Nov 2001 19:05:03 +0100 Date: Fri, 30 Nov 2001 19:12:16 +0100 (CET) From: Peter Eisentraut [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] To: PostgreSQL Development [EMAIL PROTECTED] Subject: [HACKERS] Backend error message style issues Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: [EMAIL PROTECTED] Status: ORr Now that we've gone through nearly one development cycle with national language support, I'd like to bring up a number of issues concerning the style of the backend error messages that make life difficult, but probably not only for the translators but for users as well. Not all of these are strictly translation issues, but the message catalogs make for a good overview of what's going on. I hope we can work through all of these during the next development period. Prefixing messages with command names - For instance, | CREATE DATABASE: permission denied This command: message style is typical for command-line programs and it's pretty useful there if you run many commands in a pipe. The same usefulness could probably be derived if you run many SQL commands in a function. (Just permission denied would be very confusing there!) If we want to use that style we should make it consistent and we should automate it. Via the command tag mechanism we already know what command we're executing, so we can automatically prefix all messages that way. It could even be switched off by the user if it's deemed annoying. Prefixing messages with function names -- The function names obviously have no meaning
Re: [HACKERS] error codes
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 code? The set of error codes should primarily be that defined by SQL99 part 2 clause 22 Status codes and PostgreSQL extensions that follow that spirit. That means that all those can't happen or all is lost anyway types should be lumped (perhaps in some implicit way) under internal error. That means, yes, an error code should be returned in every case of an error, but it doesn't have to be a distinct error code for every condition. How should the backend code signal an error with an error number? The problem here is that many errors will require more information that that, in order for the client to handle them properly. For example, how should a COPY indicate that an RI violation has occured? Ideally, we'd like to allow the client application to know that in line a, column b, the literal value 'c' was not found in the referenced column d of the referenced table d. Precisely. You will find that SQL99 part 2 clause 19 Diagnostics management defines all the fields that form part of a diagnostic (i.e., error or notice). This includes for example, fields that contain the name and schema of the table that was involved, if appropriate. (Again, appropriate PostgreSQL extensions could be made.) It is recommendable that this scheme be followed, so PL/pgSQL and ECPG, to name some candidates, could implement the GET DIAGNOSTICS statement as in the standard. (Notice that, for example, a diagnostic still contains a text message in addition to a code.) How should the error number be sent to the client, and would this require an FE/BE change? I think we can avoid that: including the error number in the error message itself, make PQgetErrorMessage() (and similar funcs) smart enough to remove the error number, and add a separate function (such as PQgetErrorNumber() ) to report the error number, if there is one. I would advise against trying to cram everything into a string. Consider the extra fields explained above. Consider being nice to old clients. Also, libpq allows that more than one error message might arrive per query cycle. Currently, the error messages are concatenated. That won't work anymore. You need a new API anyway. You need a new API for notices, too. One possiblity to justify a protocol change is to break something else with it, like a new copy protocol. On a related note, it would be nice to get a consistent style of punctuation for elog() messages -- currently, some of them end in a period (e.g. Database xxx does not exist in the system catalog.), while the majority do not. Which is better? Yup, we've talked about that some time ago. I have a style guide mostly worked out for discussion. It would be relatively easy to replace elog() with a macro of the form: #define elog(...) real_elog(__FILE__, __LINE__, __VA_ARGS__) And then adjust real_elog() to report that information as appropriate. And it would be relatively easy to break every old compiler that way... -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] error codes
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 error, etc.) Perhaps for those error messages that don't have numbers, we could just give them ERRNO_UNKNOWN or a similar constant. It might be cool to a little command utility pg_error or whatever that you pass an error code to and it prints out a very detailed description of the problem... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
