Re: MySQL search query is not executing in Postgres DB

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: MySQL search query is not executing in Postgres DB
Дата
Msg-id 26904.1354044374@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: MySQL search query is not executing in Postgres DB  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: MySQL search query is not executing in Postgres DB  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: MySQL search query is not executing in Postgres DB
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: WIP json generation enhancements