Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> I can think of 4 ways to fix this:
> 1) Have psql parse the script into separate commands for us.
> 2) Pull enough of psql's parsing into the backend code to be able to do #1
> 3) Add *file* line numbers to the output of pg_parse_query()
> 4) Have ereport spit out the context you'd normally get from SPI if it
> sees that it was called from somewhere underneath execute_sql_string().
> My preference would actually be #1, because that would make it easy for
> any tool that wanted to to get access to that. Jon Erdman actually
> looked into a similar alternative in the past and it was only a few
> lines of code.
So, CREATE EXTENSION would fail outright if the backend couldn't locate a
psql executable? Seems like a nonstarter to me (psql is not necessarily
installed in a server).
There's certainly room to improve error reporting for extension scripts,
but I think you are heading into a dead end in the name of saving a little
time coding. I'd suggest looking into an errcontext callback, instead.
Also, there's some technology in CREATE FUNCTION that deals with the fact
that we may be calling the parser on a string different from the original
user command, which might be worth borrowing here --- at least part of
the confusion is that it's evidently reporting a cursor position relative
to the extension script as though it applied to the CREATE EXTENSION.
regards, tom lane
