| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Michael Banck <mbanck(at)gmx(dot)net>, Tommy Pavlicek <tommypav122(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR) |
| Date: | 2024-10-13 17:13:51 |
| Message-ID: | 3482022.1728839631@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> so 12. 10. 2024 v 9:33 odesílatel jian he <jian(dot)universality(at)gmail(dot)com>
> napsal:
>> + /*
>> + * If we have a location (which, as said above, we really always should)
>> + * then report a line number to aid in localizing problems in big scripts.
>> + */
>> + if (location >= 0)
>> so this part will always be true?
> yes, after CleanQuerytext the location should not be -1 ever
Right, but we might not have entered either of those previous
if-blocks. The question here is whether the raw parser (gram.y)
ever throws an error that doesn't include a cursor position. IMO it
shouldn't, but a quick look through gram.y finds a few ereports that
lack parser_errposition. We could go fix those, and probably should,
but imagining that none will ever be introduced again seems like
folly.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-10-13 20:10:39 | Re: general purpose array_sort |
| Previous Message | Pavel Stehule | 2024-10-13 16:48:03 | Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR) |