Re: [HACKERS] Better handling of parse errors
Patch applied. Thanks. --- Gavin Sherry wrote: On Wed, 14 Aug 2002, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: ... do we want to modify every 7.2 error message? Nyet ... but I don't think tacking an offset onto the end of parse error at or near foo messages is likely to cause the sort of generalized havoc you suggest ... In that case, attached is a patch which locates the beginning of the offending token more efficiently (per your suggestion of using scanbuf). The new patch does the same as before: template1=# select * frum pg_class; ERROR: parser: parse error at or near frum at character 10 It also implement's Tom's suggestion: template1=# select * from pg_class where\g ERROR: parse: parse error at end of input Gavin Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Better handling of parse errors
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Gavin Sherry wrote: On Wed, 14 Aug 2002, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: ... do we want to modify every 7.2 error message? Nyet ... but I don't think tacking an offset onto the end of parse error at or near foo messages is likely to cause the sort of generalized havoc you suggest ... In that case, attached is a patch which locates the beginning of the offending token more efficiently (per your suggestion of using scanbuf). The new patch does the same as before: template1=# select * frum pg_class; ERROR: parser: parse error at or near frum at character 10 It also implement's Tom's suggestion: template1=# select * from pg_class where\g ERROR: parse: parse error at end of input Gavin Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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] Better handling of parse errors
On Wed, 14 Aug 2002, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: ... do we want to modify every 7.2 error message? Nyet ... but I don't think tacking an offset onto the end of parse error at or near foo messages is likely to cause the sort of generalized havoc you suggest ... In that case, attached is a patch which locates the beginning of the offending token more efficiently (per your suggestion of using scanbuf). The new patch does the same as before: template1=# select * frum pg_class; ERROR: parser: parse error at or near frum at character 10 It also implement's Tom's suggestion: template1=# select * from pg_class where\g ERROR: parse: parse error at end of input Gavin scanner2.diff.gz Description: GNU Zip compressed data ---(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] Better handling of parse errors
Gavin, have you answered these issues brought up about the patch? --- Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: Attached is a small patch to scan.l for consideration. It hands yyerror() the position in the query string of the token which caused a parse error. Isn't that the hard way to do it? Seems like you could just subtract scanbuf from the error pointer, instead of adding overhead to the basic lex loop. Things that need to be decided (and documented somewhere): Is the number an offset (counted from 0) or an index (counted from 1)? Which end of the token does it point at? Can the message be phrased so as to make it reasonably clear what the number is? A related change I'd been meaning to make is to get it to say parse error at end of input when that's the case, rather than the rather useless parse error at or near that you get now. I'd still be inclined to just say end of input in that case, and not bother with a character count. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Better handling of parse errors
Bruce, I was working on this on the train this morning. There are a few possibilities I'd like to look at before I submit another patch. Before I do, there is one important question that I didn't raise when I submitted the first patch (which was only a proof of concept kind of patch). Namely: do we want to modify every 7.2 error message? Many people have written error message parsers into their applications to make up for the fact that Postgres doesn't use error codes or issue 'standardised' error messages. Is this going to annoy people too much? Should it be delayed until we have SQL99 diagnostics/error codes? Gavin On Wed, 14 Aug 2002, Bruce Momjian wrote: Gavin, have you answered these issues brought up about the patch? --- Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: Attached is a small patch to scan.l for consideration. It hands yyerror() the position in the query string of the token which caused a parse error. Isn't that the hard way to do it? Seems like you could just subtract scanbuf from the error pointer, instead of adding overhead to the basic lex loop. Things that need to be decided (and documented somewhere): Is the number an offset (counted from 0) or an index (counted from 1)? Which end of the token does it point at? Can the message be phrased so as to make it reasonably clear what the number is? A related change I'd been meaning to make is to get it to say parse error at end of input when that's the case, rather than the rather useless parse error at or near that you get now. I'd still be inclined to just say end of input in that case, and not bother with a character count. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Better handling of parse errors
I don't think anyone will mind, but you can throw a message to 'general' just to be sure. --- Gavin Sherry wrote: Bruce, I was working on this on the train this morning. There are a few possibilities I'd like to look at before I submit another patch. Before I do, there is one important question that I didn't raise when I submitted the first patch (which was only a proof of concept kind of patch). Namely: do we want to modify every 7.2 error message? Many people have written error message parsers into their applications to make up for the fact that Postgres doesn't use error codes or issue 'standardised' error messages. Is this going to annoy people too much? Should it be delayed until we have SQL99 diagnostics/error codes? Gavin On Wed, 14 Aug 2002, Bruce Momjian wrote: Gavin, have you answered these issues brought up about the patch? --- Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: Attached is a small patch to scan.l for consideration. It hands yyerror() the position in the query string of the token which caused a parse error. Isn't that the hard way to do it? Seems like you could just subtract scanbuf from the error pointer, instead of adding overhead to the basic lex loop. Things that need to be decided (and documented somewhere): Is the number an offset (counted from 0) or an index (counted from 1)? Which end of the token does it point at? Can the message be phrased so as to make it reasonably clear what the number is? A related change I'd been meaning to make is to get it to say parse error at end of input when that's the case, rather than the rather useless parse error at or near that you get now. I'd still be inclined to just say end of input in that case, and not bother with a character count. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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] Better handling of parse errors
Gavin Sherry [EMAIL PROTECTED] writes: ... do we want to modify every 7.2 error message? Nyet ... but I don't think tacking an offset onto the end of parse error at or near foo messages is likely to cause the sort of generalized havoc you suggest ... I'm on record as favoring a thorough redesign of the error-reporting facility, and I hope to see that happen in conjunction with a frontend protocol change in 7.4. But I think your proposed change in this patch is fairly harmless and could be done now. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster