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

2022年8月3日(水) 7:56 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
> 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.

I think given this patch has gone nowhere for the past year, we can mark
it as returned with feedback. If there's potential for the items mentioned
by Tom and someone wants to run with them, that'd be better done
with a fresh entry, maybe referencing this one.

Regards

Ian Barwick