Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR) - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
Date
Msg-id CAFj8pRBGquZK3aTYvN559FFqa=bMXEuxZZBLc6kMd671u62hTQ@mail.gmail.com
Whole thread Raw
In response to Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
List pgsql-hackers
Hi

út 8. 10. 2024 v 22:18 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
I wrote:
> ... There's still a question
> of whether reporting the whole script as the query is OK when
> we have a syntax error, but I have no good ideas as to how to
> make that terser.

I had an idea about this: we can use a pretty simple heuristic
such as "break at semicolon-newline sequences".  That could fail
and show you just a fragment of a statement, but that still seems
better than showing a whole extension script.  We can ameliorate
the problem that we might not show enough to clearly identify
what failed by including a separate line number counter.
In the attached v4 I included that in the context line that
reports the script file, eg

+CONTEXT:  SQL statement "CREATE OR REPLACE FUNCTION ext_cor_func() RETURNS text
+  AS $$ SELECT 'ext_cor_func: from extension'::text $$ LANGUAGE sql"
+extension script file "test_ext_cor--1.0.sql", near line 8

This way seems a whole lot more usable when dealing with a
large extension script.

I tested it and it is working nicely.  I tested it against Orafce and I found an interesting point. The body of plpgsql functions is not checked.

Do you know the reason?

Regards

Pavel



                        regards, tom lane

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: POC, WIP: OR-clause support for indexes
Next
From: Andrew Dunstan
Date:
Subject: Re: sunsetting md5 password support