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 1354009618.10198.177.camel@jdavis-laptop
Whole thread Raw
In response to Re: MySQL search query is not executing in Postgres DB  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: MySQL search query is not executing in Postgres DB  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sun, 2012-11-25 at 21:08 -0500, Robert Haas wrote:
> That, however, is a separate question from what's under discussion
> here, because the case at issue for the proposed patch is the one in
> which only one possible candidate exists, and the question is whether
> we ought to allow the use of assignment casts to allow the call to
> work rather than fail, NOT which of several overloaded functions we
> ought to pick.  In any situation in which overloading is in use, the
> patch as proposed changes nothing.  I'm not generally very good at
> interpreting the SQL standard text, but if it says that you ought to
> use assignment casts to match actual argument types to the chosen
> candidate function, then that seems like it's advocating for
> essentially the same position that you arrived at independently and
> that the patch also takes, which furthermore happens to be compatible
> with what other RDBMS systems do, at least in the no-overloading case.

Let's say you have only one function "foo". All your queries are coded
into your application, and everything works fine, using assignment casts
where necessary.

Then the user is foolish enough to CREATE FUNCTION foo... and now their
queries start failing left and right.

In other words, "only one possible candidate exists" should be followed
by "right now" to be more precise.

That's a major violation of the principle of least astonishment, that
CREATE FUNCTION could cause such a disaster. I know that it can now, but
what you're proposing will come into play much more frequently because
most people start off with just one function by a particular name and
define more as needed.

If we do something like this, I think we should explicitly opt out of
the overloading feature at DDL time (somewhat like what Simon suggested
in another reply). E.g. CREATE {UNIQUE|OVERLOADED} FUNCTION ...

I'm not proposing that; in general I am very wary of changes to the type
system. I'm just saying that, if we do have special rules, we should
have a way to make sure that users know when the rules are changing.

Regards,Jeff Davis





pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Plugging fd leaks (was Re: Switching timeline over streaming replication)
Next
From: Piyush Newe
Date:
Subject: Re: gset updated patch