From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME |
Date: | 2017-12-31 16:57:02 |
Message-ID: | 25393.1514739422@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Yugo Nagata <nagata(at)sraoss(dot)co(dot)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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Remi Colinet | 2017-12-31 17:00:05 | [Patch] Make block and file size for WAL and relations defined at cluster creation |
Previous Message | Peter Geoghegan | 2017-12-31 16:29:02 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |