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

From Robert Haas
Subject Re: MySQL search query is not executing in Postgres DB
Date
Msg-id CA+TgmoayyZ2ZCzaSb4SaWAeQFOTk4+8Yc3XR4e4Crx=an7jkXw@mail.gmail.com
Whole thread Raw
In response to Re: MySQL search query is not executing in Postgres DB  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: MySQL search query is not executing in Postgres DB  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: MySQL search query is not executing in Postgres DB  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Thu, Nov 22, 2012 at 10:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The argument here is basically between ease of use and ability to detect
> common programming mistakes.  It's not clear to me that there is any
> principled way to make such a tradeoff, because different people can
> reasonably put different weights on those two goals.

I think that is true.  But for whatever it's worth, and at the risk of
beating a horse that seems not to be dead yet in spite of the fact
that I feel I've already administered one hell of a beating, the LPAD
case is unambiguous, and therefore it is hard to see what sort of
programming mistake we are protecting users against.  If there's only
one function called bob, and the user says bob(x), it is hard to see
what behavior, other than calling bob with x as an argument, would be
even mildly sensible.  (Yes, OK, there are two lpad functions, but as
you pointed out previously, they take different numbers of arguments,
so the point still stands.)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: MySQL search query is not executing in Postgres DB
Next
From: Josh Berkus
Date:
Subject: Re: MySQL search query is not executing in Postgres DB