Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID
Дата
Msg-id CAFj8pRA+gVd2M4TJ+Hs4ibGW4N5zRwjvwQph1z2X+y_GjeAGqw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID
Список pgsql-hackers


út 4. 4. 2023 v 16:20 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> There is reduced patch + regress tests

One more thing: I do not think it's appropriate to allow this in
GET STACKED DIAGNOSTICS.  That's about reporting the place where
an error occurred, not the current location.  Eventually it might
be interesting to retrieve the OID of the function that contained
the error, but that would be a pretty complicated patch and I am
not sure it's worth it.  In the meantime I think we should just
forbid it.

If we do that, then the confusion you were concerned about upthread
goes away and we could shorten the keyword back down to "pg_routine_oid",
which seems like a good thing for our carpal tunnels.

Thoughts?

has sense

updated patch attached

Regards

Pavel

                        regards, tom lane
Вложения

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

Предыдущее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: Minimal logical decoding on standbys
Следующее
От: Tom Lane
Дата:
Сообщение: Re: psql: Add role's membership options to the \du+ command