Re: proposal: better support for debugging of overloaded functions
От | Pavel Stehule |
---|---|
Тема | Re: proposal: better support for debugging of overloaded functions |
Дата | |
Msg-id | CAFj8pRAOQOF59WUgw72RRVHr9VUiEn+kPA9mXfyOOaO1bJiFpg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: better support for debugging of overloaded functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: proposal: better support for debugging of overloaded functions
|
Список | pgsql-hackers |
2011/11/18 Robert Haas <robertmhaas@gmail.com>: > On Fri, Nov 18, 2011 at 6:24 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: >> CONTEXT: PL/pgSQL function "assign_rslts" line 50 at assignment (oid: 65903) >> >> \sf+ 65903 > > I'm pretty unenthused by the idea of making OIDs more user-visible > than they already are. If the message is ambiguous, we should include > argument types and (if not the object that would be visible under the > current search_path) a schema qualification. Spitting out a five (or > six or seven or eight) digit number doesn't seem like a usability > improvement. Is possible to add GUC variable plpgsql.log_function_signature (maybe just log_function_signature (for all PL))? I am not sure about GUC name. When this variable is true, then CONTEXT line will contain a qualified function's signature instead function name I don't would to check if function name is ambiguous or not after exception is raised. There is a problem with access to system tables and then exception handling can be slower. Using a qualified name is necessary, because psql meta statements are not "smart" - they are based on search_path and fact, so name is not ambiguous doesn't help there. Regards Pavel Stehule p.s. Other issue is missing CONTEXT line for RAISE EXCEPTION > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
В списке pgsql-hackers по дате отправления: