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

Поиск
Список
Период
Сортировка
От Ian Lawrence Barwick
Тема Re: [PROPOSAL] new diagnostic items for the dynamic sql
Дата
Msg-id CAB8KJ=itSk7LZZPYmQ3gt6wmLWbAGBZiqAVEOhbCts3B_X9zWA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PROPOSAL] new diagnostic items for the dynamic sql  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
2022年8月3日(水) 7:56 Tom Lane <tgl@sss.pgh.pa.us>:
>
> Jacob Champion <jchampion@timescale.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ian Lawrence Barwick
Дата:
Сообщение: Re: Allow parallel plan for referential integrity checks?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: GetNewObjectId question