Re: proposal: better support for debugging of overloaded functions - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: better support for debugging of overloaded functions
Date
Msg-id CAFj8pRB5APjWdhsW7cPbPWWMy785P493V=Uq=rgdei039UBe3A@mail.gmail.com
Whole thread Raw
In response to Re: proposal: better support for debugging of overloaded functions  (Robert Haas <robertmhaas@gmail.com>)
List 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.
>

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
>


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: testing ProcArrayLock patches
Next
From: "Kevin Grittner"
Date:
Subject: Re: testing ProcArrayLock patches