Re: Implicit coercions need to be reined in

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Implicit coercions need to be reined in
Дата
Msg-id
6024.1019052874@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Re: Implicit coercions need to be reined in "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Implicit coercions need to be reined in Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart  writes:
> I'd like to see a continuing discussion of this before leaping to a
> conclusion; now that we have (somewhat) more control over coersions some
> additional tuning is certainly warranted but hopefully it will not
> require removing reasonable and convenient behaviors.

Absolutely --- that's why I started this latest round of discussion.

What I'm really looking for is a way that we can allow (some?) implicit
text coercions while getting rid of the sort of misbehavior exemplified
by that bug report I keep referring to.  Has anyone got any ideas about
how to do that?  It's one thing to say that "apples || oranges" should
be interpreted as "apples::text || oranges::text", but it is quite
another to say that "apples <= oranges" should be handled that way.

Also: now that we can create non-implicit coercion functions, I would
like to add functions for bool<->int, numeric<->text, and other
coercions that would be handy to have, but previously we resisted on
the grounds that they'd turn the type checking system into a joke.
But perhaps some of these *should* be allowed as implicit coercions.
I'd like to develop a well-thought-out policy for which coercions should
be implicit, rather than making ad-hoc decisions.

So far the only policy-like idea that I've had is to forbid cross-type-
category implicit coercions.  That would solve the comparing-apples-to-
oranges problem; but if people think it'd cause too much collateral
damage, how about proposing some other rule?
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Michael Loftis
Дата:
От: Thomas Lockhart
Дата:
FAQ