Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID
Дата
Msg-id 1244928.1680543451@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> po 27. 3. 2023 v 5:36 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
>> I have marked the item Ready for Commiter...

> Thank you for doc and for review

I'm kind of surprised there was any interest in this proposal at all,
TBH, but apparently there is some.  Still, I think you over-engineered
it by doing more than the original proposal of making the function OID
available.  The other things can be had by casting the OID to regproc
or regprocedure, so I'd be inclined to add just one new keyword not
three.  Besides, your implementation is a bit inconsistent: relying
on fn_signature could return a result that is stale or doesn't conform
to the current search_path.

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: SQL/JSON revisited
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Why enable_hashjoin Completely disables HashJoin