Re: Implicit coercions need to be reined in

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: Implicit coercions need to be reined in
Дата
Msg-id 20011121125611.Y67806-100000@megazone23.bigpanda.com
обсуждение исходный текст
Ответ на Implicit coercions need to be reined in  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, 21 Nov 2001, Tom Lane wrote:

> It strikes me that this is a bad idea, and will get a lot worse as we
> add more conversion functions.  With enough implicit coercions one will
> never be entirely sure how the system will interpret a mixed-datatype
> expression.  Nonetheless, having more conversion functions seems like a
> good idea --- I think there should be a numeric-to-text conversion
> function, for example, and someone was just complaining in pggeneral
> about the lack of a boolean-to-text coercion.  The problem is that
> there's no way to create a conversion function without inducing an
> implicit coercion path (unless you give the function a nonobvious name).
>
> What I'd like to suggest (for 7.3 or later) is adding a boolean column
> to pg_proc that indicates "can be implicit coercion".  A function for
> which this is not set can be used as an explicitly requested coercion,
> but not an implicit one.  Thus it'd be possible to define text(boolean)
> and allow it to be called explicitly, without creating an implicit
> coercion path and thereby losing a lot of type safety.

I think something of this sort is a good thing. :) It's a bit of a pain in
one way, but it makes understanding what's going on simpler, especially
given things like the person who was getting text cut off at 31 or
whatever characters due to the fact that there was an implicit coercion
through name.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Further open item (Was: Status of 7.2)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: beta3