Re: Odd procedure resolution

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Odd procedure resolution
Date: 2018-05-21 04:40:59
Message-ID: CAFjFpRc5KFaSW=eTPVS+yt-dguj4cn=m63KjT+neeFH6dcFq4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 19, 2018 at 12:51 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, May 17, 2018 at 4:10 PM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> I think I have made a mistake here. I was reading in between the lines
>> of a competitor's documentation that they have functions and procedures
>> in different name spaces, which made me re-read the SQL standard, which
>> appears to support that approach.
>
> I am really doubtful about trying to merge those completely. You end
> up with confusion about what DROP ROUTINE actually means, for example.
> Also, I am quite dubious about the idea that functions, window
> functions, and aggregates should go all together into one namespace
> and procedures into a completely different one. I thought merging all
> of that stuff down into prokind was quite elegant, and I'm not too
> excited about seeing that change backed out. Functions, procedures,
> aggregates, and window functions are all function-like things -- given
> any one of them, you might end up writing something like
> mything(thingarg1, thingarg2) in some context or other. I think it is
> very sensible to say that we won't let you create two such things with
> identical signature, because that's just confusing -- and probably of
> very doubtful utility. At the same time, I don't think that precludes
> using context clues to figure out which one must have been intended in
> a particular SQL statement. There are cases where something must
> "become all one thing or all the other", but I don't see why that
> should be true here.

+1 for all that.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2018-05-21 04:48:46 Re: Postgres, fsync, and OSs (specifically linux)
Previous Message Tom Lane 2018-05-21 04:36:53 Re: Allowing printf("%m") only where it actually works