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

From Tom Lane
Subject Re: MySQL search query is not executing in Postgres DB
Date
Msg-id 26904.1354044374@sss.pgh.pa.us
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
Robert Haas <robertmhaas@gmail.com> writes:
> But as to your point about the system catalogs, it is true that adding
> an additional function could reduce the number of cases where things
> work today.  But I think in many cases it would eliminate the need for
> overloading that we already have, and simplify things for future
> developers.  Right now, quote_literal() allows implicit casts to text
> by having a second version that takes any anyelement argument; on the
> other hand, concat() allows implicit casts to text by accepting "any"
> rather than text as an argument; and || allows implicit casts to text
> by defining operators for anynonarray || text, text || anynonarray,
> and text || text.  So we've got three quite different methods to
> create implicit-cast-to-text behavior in particular cases.  That's got
> developer complexity too, and while this proposal wouldn't do anything
> about the third case since || actually sometimes has a different
> meaning, namely array concatenation, the first two wouldn't need
> overloading any more.  They'd just work.

Uh, no, not really, and I think that assertion just goes to show that
this area is more subtle than you think.  quote_literal() for instance
presently works for any datatype that has an explicit cast to text.
After making the change you propose above, it would only work for types
for which the cast was assignment-grade or less.  concat() is even
looser: as now implemented, it works for *anything at all*, because it
relies on datatype output functions not casts to text.  I'm dubious that
that inconsistency is a good thing, actually, but that's how the
committed code is written.

Now, some of us might think that backing these conversions down to only
allowing assignment-grade casts would be an improvement, in the sense
that it would actually make the type system tighter not looser than it
is today for these particular functions.  But I suspect you wouldn't see
it as an improvement, given the position you're arguing from.

In fact, I'm afraid that making this change would result in requests to
downgrade existing explicit casts to be assignment-only, so that people
could be even lazier about not casting function arguments; and that is
something up with which I will not put.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: MySQL search query is not executing in Postgres DB
Next
From: Andrew Dunstan
Date:
Subject: Re: WIP json generation enhancements