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.
By the way, if we're going to start worrying about which namespaces
certain competitors put things in, I believe investigation will show
that in at least one notable case, the existing differences are rather
far-reaching and well beyond our ability to fix without major
restructuring of our system catalogs and, I think, abandoning bison.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company