On Tue, 2012-11-27 at 15:41 -0500, Robert Haas wrote:
> I can't quite see how a non-overloaded flag would work, unless we get
> rid of schemas.
It may work to pick the first schema in the search path that has any
functions by that name, and then choose the overloaded (or not)
candidate from among those functions in that one schema. Then,
non-overloaded function names would be unique within a schema.
If there are multiple functions of the same name in multiple schemas in
the search path, it does not make sense to me to lump them all together
and choose an overloaded candidate from all of them (although I think
that's what we do now). That sounds like a mistake, to me. Do you know
of any useful examples of doing that?
> But I think there are a variety of other kinds of
> labeling that I think would work.
Worth exploring.
> I'm still not sure that's as good
> as a general solution, because if nothing else it relies on us to make
> the right decision as to which type to use in each case, and
> considering that neither Tom nor I are particularly sold on what we
> did with CONCAT(), nor am I sure that we even agree with each other on
> what the right thing to do would have been there, I'm a bit skeptical
> about our ability to get these decisions right. But it might still be
> an improvement.
I'm not entirely clear on the benefits of a general solution, nor why
your solution is more general. You are still categorizing functions into
"overloaded" and "non-overloaded", but you are doing so at runtime based
on the current contents of the catalog.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
