On 1/12/16 5:00 PM, Tom Lane wrote:
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.
Are you talking about plpgsql_compile_error_callback()? It looks like it
does it's magic by relying on the plpgsql parser to keep track of where
it's at.
ISTM part of the goal here should be to show what the actual command was
that failed (ie: the command in the extension file). I'm guessing the
way to do that would be to have pg_parse_query() keep the original
statement in the parse nodes?
I guess if this was easy it would already have been fixed...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
