Re: MySQL search query is not executing in Postgres DB

On 12/14/2012 3:20 PM, Robert Haas wrote:
> On Fri, Dec 14, 2012 at 2:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> ... In more
>>> than ten years of working with PostgreSQL, I've never encountered
>>> where the restriction at issue here prevented a bug. It's only
>>> annoyed me and broken my application code (when moving from PostgreSQL
>>> 8.2 to PostgreSQL 8.3, never mind any other database!).
>>
>> There are quite a few examples in our archives of application bugs that
>> would have been prevented, or later were prevented, by the 8.3 changes
>> that reduced the system's willingness to apply implicit casts to text.
>> I recall for instance cases where people got wrong/unexpected answers
>> because the system was sorting what-they-thought-were-timestamp values
>> textually.
>>
>> So I find such sweeping claims to be demonstrably false, and I'm
>> suspicious of behavioral changes that are proposed with such arguments
>> backing them.
>
> I think you're mixing apples and oranges. The whole point of the
> patch on the table - which, if you recall, was designed originally by
> you and merely implemented by me - was to change the behavior only in
> the cases where there's only one function with the appropriate name
> and argument count. The ambiguous cases that 8.3+ helpfully prevent
> are those where overloading is in use and the choice of which function
> to call is somewhat arbitrary and perhaps incorrectly-foreseen by the
> user. Those changes also have the side-effect of preventing a
> straightforward function call from working without casts even in cases
> where no overloading is in use - and making that case work is
> completely different from making the ambiguous case arbitrarily pick
> one of the available answers.

FWIW I for one thought that casting more liberal in the case at hand,
where there is only one function with that name and number of arguments,
would be a good thing. My only concern with the patch presented was that
changing make_fn_assignment() in that way may have some unwanted side
effects because it is called from different locations and the usage of
COERCION_IMPLICIT may actually guard against something, that we don't
want to allow. I don't have any evidence that it does, just the concern
that it may.

Perhaps make_fn_arguments() needs to receive that coercion context as an
argument and the caller hands in COERCION_ASSIGNMENT only in the case at
hand?

Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin