On Sat, May 19, 2018 at 12:51 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, May 17, 2018 at 4:10 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.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
