Re: [PROPOSAL] new diagnostic items for the dynamic sql

Jacob Champion <jchampion(at)timescale(dot)com> writes:
> ...and Dinesh's email has just bounced back undelivered. :(

> Anybody interested in running with this? If no one speaks up, I think we
> should return this as "needs more interest" before the next CF starts.

Meh ... the last versions of the patch were far too invasive for a
use-case that seemed pretty hypothetical to begin with. It was never
explained why somebody would be trying to debug dynamic SQL without
use of the reporting that already exists:

regression=# do $$ begin
regression$# execute 'SELECT 1 JOIN SELECT 2';
regression$# end $$;
ERROR: syntax error at or near "SELECT"
LINE 1: SELECT 1 JOIN SELECT 2
^
QUERY: SELECT 1 JOIN SELECT 2
CONTEXT: PL/pgSQL function inline_code_block line 2 at EXECUTE

psql didn't provide that query text and cursor position out of thin air.

Now admittedly, what it did base that on is the PG_DIAG_INTERNAL_QUERY and
PG_DIAG_INTERNAL_POSITION fields of the error report, and the fact that
those aren't available to plpgsql error trapping logic is arguably a
deficiency. It's not a big deficiency, because what an EXCEPTION clause
probably ought to do in a case like this is just re-RAISE, which will
preserve those fields in the eventual client error report. But maybe
it's worth fixing.

I think the real reason this patch stalled is that Pavel wanted the
goal posts moved into the next stadium. Rather than just duplicate
the functionality available in the wire protocol, he wanted some other
definition entirely, hiding the fact that not every error report has
those fields. There isn't infrastructure for that, and I doubt that
this patch is enough to create it, even if there were consensus that
the definition is right. If we were to go forward, I'd recommend
reverting to a wire-protocol-equivalent definition, and just returning
NULL in the cases where the data isn't supplied.

regards, tom lane