From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: better support for debugging of overloaded functions |
Date: | 2011-11-18 18:13:36 |
Message-ID: | CAFj8pRB5APjWdhsW7cPbPWWMy785P493V=Uq=rgdei039UBe3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/11/18 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Fri, Nov 18, 2011 at 6:24 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.
>
yes - it's not nice - but it is simple and robust and doesn't depend
on actual search_path setting.
Nicer solution is a function signature - it can be assembled when
function is compiled. I see only one disadvantage - signature can be
too wide and can depend on search_path (and search_path can be
different when function is executed and when someone run sql console).
Signature should be prepared before execution, because there are no
access to system tables after exception.
I like any solution, because debugging of overloaded function is terrible now.
Regards
Pavel
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-11-18 18:14:56 | Re: testing ProcArrayLock patches |
Previous Message | Robert Haas | 2011-11-18 17:51:28 | Re: testing ProcArrayLock patches |