Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> I think we must extend pg_cast's castimplicit column to a three-way value:
>> * okay as implicit cast in expression (or in assignment)
>> * okay as implicit cast in assignment only
>> * okay only as explicit cast
> As the user of a cast, these options make the whole system nearly
> unpredictable because in any non-trivial expression each of these
> behaviors could take effect somehow (possibly even depending on how the
> inner expressions turned out).
How so? Only the first set of casts applies inside an expression.
It seems to me that this proposal actually *reduces* the number of casts
that might apply in any given context, and thus makes the behavior more
predictable not less so. Certainly it is more predictable than
any-cast-can-be-applied-implicitly, which I seem to remember you arguing
for (at least for the numeric types).
> I am not aware of any programming language that has more than three
> castability levels (never/explicit/implicit).
Actually I think that this scheme would allow us to model typical
programming-language behavior quite accurately. C for example will let
you assign a float to an integer (with appropriate runtime behavior) ---
but if you add a float and an integer, you get a float addition; there's
no possibility that the system will choose to coerce the float to int
and do an int addition. So the set of available implicit casts is
different in an assignment context than it is in an expression context.
Seems pretty close to what I'm suggesting.
> Finally, I believe this paints over the real problems, namely the
> inadequate and hardcoded type category preferences and the inadequate
> handling of numerical constants. Both of these issues have had adequate
> approaches proposed in the past and would solve this an a number of other
> issues.
If they were adequate they would have gotten implemented; we had issues
with all the proposals so far. See my later response to Andreas for a
possible solution to the numerical-constant issue based on this
mechanism.
regards, tom lane
