Re: MySQL search query is not executing in Postgres DB

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, premanand <kottiprem(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: MySQL search query is not executing in Postgres DB
Date: 2012-08-30 13:06:39
Message-ID: 20120830130639.GA4314@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 29, 2012 at 06:39:37PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On the more general issue, I continue to see minimal risk of harm
> > in allowing things like LPAD() to implicitly cast the first
> > argument to text.
>
> Well, I see your point about LPAD(), but the problem is how to tell
> the difference between a harmless cast omission and an actual
> mistake that the user will be very grateful if we point out. If we
> allow implicit casts to text in the general case in
> function/operator calls, we are definitely going to re-introduce a
> lot of room for mistakes.
>
> Upthread you were complaining about how we'd reject calls even when
> there was only one possible interpretation. I wonder whether
> there'd be any value in taking that literally: that is, allow use of
> assignment rules when there is, in fact, exactly one function with
> the right number of parameters visible in the search path.

+1 for this.

> The main downside I can see is that code that used to work is likely
> to stop working as soon as someone creates a potential overloading
> situation. Worse, the error message could be pretty confusing,
> since if you had been successfully calling f(smallint) with f(42),
> you'd get "f(integer) does not exist", not something like "f() is
> ambiguous", after adding f(float8) to the mix. This seems related
> to the confusing changes in regression test cases that I got in my
> experiments yesterday. This may be sufficient reason to reject the
> idea, since the very last thing we need in this area is any
> degradation in the relevance of the error messages.

With the ANY* parameters introduced in the past few versions, there's
a lot less incentive to create this problem. The trick here is
documenting the ANY* parameters in enough places to make sure that
incentive is reduced.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-08-30 13:13:08 Re: MySQL search query is not executing in Postgres DB
Previous Message Dave Page 2012-08-30 12:39:36 Re: _USE_32BIT_TIME_T Patch