Re: proposal: better support for debugging of overloaded functions

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
>

In response to

Browse pgsql-hackers by date

  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