Re: MySQL search query is not executing in Postgres DB - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: MySQL search query is not executing in Postgres DB
Date
Msg-id 1355470529.11945.5.camel@jdavis
Whole thread Raw
In response to Re: MySQL search query is not executing in Postgres DB  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Tue, 2012-11-27 at 14:24 -0800, Jeff Davis wrote:
> 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?

On second thought, this won't work very well, particularly for
operators. Users may want to overload a built-in operator, like "+", yet
still have it work on all the built-in types.

So, if we did try to declare a function non-overloaded at DDL time, the
name would have to be globally unique (not just to a schema).

Regards,Jeff Davis




pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: MySQL search query is not executing in Postgres DB
Next
From: Jeff Davis
Date:
Subject: Re: Doc patch to note which system catalogs have oids