Re: Implicit coercions need to be reined in - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: Implicit coercions need to be reined in
Date
Msg-id 20011121125611.Y67806-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Implicit coercions need to be reined in  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Further open item (Was: Status of 7.2)
Next
From: Tom Lane
Date:
Subject: Re: beta3