Currently, if PG has a single-argument function named after its result
type, the function is assumed to represent a valid implicit type
coercion. For example, I can do
regression=# select now() || now(); ?column?
------------------------------------------------------------2001-11-21 15:12:13.226482-052001-11-21 15:12:13.226482-05
(1 row)
because there is a function text(timestamp) returning text, and
this function gets invoked implicitly.
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 have not gone over the existing implicit coercions to see which ones
I like and don't like, but I think a good first cut at maintaining
sanity would be to disable any cross-type-category implicit coercions.
Thus, for example, int4 to float8 seems like an okay implicit coercion,
but not int4 to text.
Note that this would cause the system to reject some things it accepts
now, for example:
regression=# select 45::int4 || 66::int4;?column?
----------4566
(1 row)
This sort of thing would need explicit coercions to text under my proposal.
Comments?
regards, tom lane