On Wed, 21 Nov 2001, Tom Lane wrote:
> "Gurunandan R. Bhat" <grbhat@exocore.com> writes:
> > The excellently detailed Postgres manual, seems to indicate that
> > the concatenation operator "||" converts the right and left operands of
> > all base types to text with the exception of boolean which cannot be cast
> > as any other type.
>
> Uh, where did you get that impression? || is a string operator only
> (and maybe a bit string and bytea operator, depending on which release
> you are using).
True. I wasnt referring to the operator per se, but rather to the ability
of the parser to "promote" a data type to text merely by virtue of the
fact that a function declared as text(boolean) is available and that an
operator "expects" certain data types as operands. I probably misread the
following extract from the manual:
Extract from Section 5.1
"...The Postgres parser uses the convention that all type conversion
functions take a single argument of the source type and are named with
the same name as the target type. Any function meeting these criteria
is considered to be a valid conversion function, and may be used by
the parser as such. This simple assumption gives the parser the power
to explore type conversion possibilities without hardcoding, allowing
extended user-defined types to use these same features transparently.
An additional heuristic is provided in the parser to allow better
guesses at proper behavior for SQL standard types. There are several
basic type categories defined: boolean, numeric, string, bitstring,
datetime, timespan, geometric, network, and user-defined. Each
category, with the exception of user-defined, has a preferred type
which is preferentially selected when there is ambiguity. In the
user-defined category, each type is its own preferred type."
> There are implicit coercions to text for some datatypes.
It appears that implicit coercions can be made to happen for all data
types except numeric and boolean. And my question was : why exclude these
two? Any special reason?
> It's my feeling that such implicit coercions are dangerous, and that
> we ought to avoid them rather than add more. Too many implicit
> coercion paths, and you'll never be sure what a multi-datatype
> expression is going to be interpreted to do.
Point. And thanks for the very clear example of the possible dangers. I
have made the appropriate changes to my code.
Thanks and regards,
Gurunandan