Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME

Поиск
Список
Период
Сортировка
От Yugo Nagata
Тема Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME
Дата
Msg-id 20180111110326.9c556d63.nagata@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME
Список pgsql-hackers
On Sun, 31 Dec 2017 11:57:02 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Yugo Nagata <nagata@sraoss.co.jp> writes:
> > Attached is a patch to implement a feature to get the current function
> > name by GET DIAGNOSTICS in PL/pgSQL function.
> 
> While this is certainly not a very large patch, it's still code that
> we'd have to maintain forever, so I think it's appropriate to ask
> some harder questions before accepting it.
> 
> 1. I'm having a hard time visualizing an actual concrete use case for
> this --- exactly when would a function not know its own name?  Neither
> your "our client wanted it" justification nor the cited stackoverflow
> question provide anything close to an adequate rationale.  I can think of
> concrete uses for an operation like "give me the name of my immediate
> caller", but that's not what this is.

Our client's use case was mainly to output debug messages at begining and
end of functions by using the same code. In addition, names of cursors
declared in the function were based on the function name, and they wanted
to get the function name to handle cursors.

However, I don't inisist on this patch, so If anyone other don't need this
feature, I'll withdraw this.

Regards,

> 
> 2. The specific semantics you've chosen --- in effect, regprocedureout
> results --- seem to be more because that was already available than
> anything else.  I can imagine wanting just the bare name, or the
> schema-qualified name, or even the numeric OID (if we're in the
> business of introspection, being able to look up the function's own
> pg_proc entry might be useful).  I'm not proposing that we offer
> all those variants, certainly, but without concrete use cases it's
> pretty hard to be sure we picked the most useful behavior.
> 
> 3. In connection with #2, I'm dubious that FUNCTION_NAME is le mot
> juste, because that would seem to imply that it is just the name,
> which it isn't.  If we stick with the regprocedureout semantics
> I'd be inclined to propose FUNCTION_SIGNATURE.
> 
>             regards, tom lane
> 


-- 
Yugo Nagata <nagata@sraoss.co.jp>


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscripting
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: BUG #14941: Vacuum crashes