Re: Odd procedure resolution
От | Ashutosh Bapat |
---|---|
Тема | Re: Odd procedure resolution |
Дата | |
Msg-id | CAFjFpRc5KFaSW=eTPVS+yt-dguj4cn=m63KjT+neeFH6dcFq4g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Odd procedure resolution (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: