
> The lines marked XXX are the ones that I enabled since yesterday, and
> would like to disable again:
> 
>  implicit |   result    |    input    |                        prosrc
> ----------+-------------+-------------+--------------------------------------

>  no       | varchar     | int8        | int8_text

Wow, I am completely at a loss why you would not allow implicit coercions
that do not loose any data in the process. 
Coercing an int to float would in some cases loose precision. It is thus imho 
debateable what to do here, but not for the rest.

I would think it a major step in the wrong direction.

Andreas

Tue, 16 Apr 2002 20:51:33 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Implicit coercions need to be reined in 
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Wow, I am completely at a loss why you would not allow implicit coercions
> that do not loose any data in the process. 

Haven't you read the previous threads?  Implicit coercions are
dangerous, because they cause the system to resolve operators in
unexpected ways.  See, eg, bug #484:
http://archives.postgresql.org/pgsql-bugs/2001-10/msg00103.php
http://archives.postgresql.org/pgsql-bugs/2001-10/msg00108.php

I'm not by any means opposed to *all* implicit coercions, but
cross-type-category ones strike me as bad news.

In particular, if all datatypes have implicit coercions to text then
type checking is pretty much a thing of the past :-( ... the system will
be able to resolve nearly anything by interpreting it as a text
operation.  See above bug.

I suspect you are going to argue that you are prepared to live with such
misbehavior because it's too darn convenient not to have to write
::text.  Well, maybe that is indeed the community consensus, but I want
to see a discussion about it first.  And in any case I want a fairly
well-defined, circumscribed policy about which implicit coercions we
will have.

			regards, tom lane

Tue, 16 Apr 2002 18:24:49 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Implicit coercions need to be reined in 
...
> Haven't you read the previous threads?  Implicit coercions are
> dangerous, because they cause the system to resolve operators in
> unexpected ways.

Sure he's read the threads. The conclusion is *not* obvious, and any
blanket statement to that effect trivializes the issues in a non-helpful
way imho.

I'd like to see a continuing discussion of this before leaping to a
conclusion; now that we have (somewhat) more control over coersions some
additional tuning is certainly warranted but hopefully it will not
require removing reasonable and convenient behaviors.

                      - Thomas

Wed, 17 Apr 2002 06:27:56 -0700
Thomas Lockhart <thomas@fourpalms.org>
Re: Implicit coercions need to be reined in
Thomas Lockhart <thomas@fourpalms.org> writes:
> I'd like to see a continuing discussion of this before leaping to a
> conclusion; now that we have (somewhat) more control over coersions some
> additional tuning is certainly warranted but hopefully it will not
> require removing reasonable and convenient behaviors.

Absolutely --- that's why I started this latest round of discussion.

What I'm really looking for is a way that we can allow (some?) implicit
text coercions while getting rid of the sort of misbehavior exemplified
by that bug report I keep referring to.  Has anyone got any ideas about
how to do that?  It's one thing to say that "apples || oranges" should
be interpreted as "apples::text || oranges::text", but it is quite
another to say that "apples <= oranges" should be handled that way.

Also: now that we can create non-implicit coercion functions, I would
like to add functions for bool<->int, numeric<->text, and other
coercions that would be handy to have, but previously we resisted on
the grounds that they'd turn the type checking system into a joke.
But perhaps some of these *should* be allowed as implicit coercions.
I'd like to develop a well-thought-out policy for which coercions should
be implicit, rather than making ad-hoc decisions.

So far the only policy-like idea that I've had is to forbid cross-type-
category implicit coercions.  That would solve the comparing-apples-to-
oranges problem; but if people think it'd cause too much collateral
damage, how about proposing some other rule?

			regards, tom lane

Wed, 17 Apr 2002 10:14:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Implicit coercions need to be reined in 
...
> What I'm really looking for is a way that we can allow (some?) implicit
> text coercions while getting rid of the sort of misbehavior exemplified
> by that bug report I keep referring to.  Has anyone got any ideas about
> how to do that?  It's one thing to say that "apples || oranges" should
> be interpreted as "apples::text || oranges::text", but it is quite
> another to say that "apples <= oranges" should be handled that way.

Hmm. istm that we might need some information to travel with the
operators, not just the coersion functions themselves. We have a fairly
type-rich system, but need to preserve the ability to add types and a
*partial* set of functions and operators and get reasonable behaviors.

                      - Thomas

Wed, 17 Apr 2002 07:42:52 -0700
Thomas Lockhart <thomas@fourpalms.org>
Re: Implicit coercions need to be reined in
Thomas Lockhart <thomas@fourpalms.org> writes:
>> It's one thing to say that "apples || oranges" should
>> be interpreted as "apples::text || oranges::text", but it is quite
>> another to say that "apples <= oranges" should be handled that way.

> Hmm. istm that we might need some information to travel with the
> operators, not just the coersion functions themselves. We have a fairly
> type-rich system, but need to preserve the ability to add types and a
> *partial* set of functions and operators and get reasonable behaviors.

Could we do anything based on looking at the whole set of candidate
operators?  For example, I think that the reason "apples || oranges"
is so appealing is that there really is only one way to interpret
the || operator; whereas of course there are lots of different <=
operators.  Perhaps we could be more forgiving of implicit coercions
when there are fewer candidate operators, in some way?  Again, something
based on type categories would make sense to me.  Perhaps allow
cross-category implicit coercions only if there are no candidate
operators accepting the input's native category?

			regards, tom lane

Wed, 17 Apr 2002 10:52:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Implicit coercions need to be reined in 
...
> Could we do anything based on looking at the whole set of candidate
> operators?  For example, I think that the reason "apples || oranges"
> is so appealing is that there really is only one way to interpret
> the || operator; whereas of course there are lots of different <=
> operators.  Perhaps we could be more forgiving of implicit coercions
> when there are fewer candidate operators, in some way?  Again, something
> based on type categories would make sense to me.  Perhaps allow
> cross-category implicit coercions only if there are no candidate
> operators accepting the input's native category?

Hmm. That might be a winner. Since everything can be turned into text,
there will always be a fallback to text available. Allow it for
operators which are text-only operators (are there any built in besides
"||"?) and disallow that fallback for the others?

One edge case which we are probably concerned about is the "typeless
literal". I'd guess that we make the right choice in *most* cases
already.

I guess I'm worried that we may be cutting back on the allowed implicit
coersions, when we might really be missing only one or two explicit
coersion functions to fill in the set. I haven't looked at that in a
while...

                   - Thomas

Wed, 17 Apr 2002 08:09:27 -0700
Thomas Lockhart <thomas@fourpalms.org>
Re: Implicit coercions need to be reined in
Tom Lane wrote:
> Thomas Lockhart <thomas@fourpalms.org> writes:
> >> It's one thing to say that "apples || oranges" should
> >> be interpreted as "apples::text || oranges::text", but it is quite
> >> another to say that "apples <= oranges" should be handled that way.
> 
> > Hmm. istm that we might need some information to travel with the
> > operators, not just the coersion functions themselves. We have a fairly
> > type-rich system, but need to preserve the ability to add types and a
> > *partial* set of functions and operators and get reasonable behaviors.
> 
> Could we do anything based on looking at the whole set of candidate
> operators?  For example, I think that the reason "apples || oranges"
> is so appealing is that there really is only one way to interpret
> the || operator; whereas of course there are lots of different <=
> operators.  Perhaps we could be more forgiving of implicit coercions
> when there are fewer candidate operators, in some way?  Again, something
> based on type categories would make sense to me.  Perhaps allow
> cross-category implicit coercions only if there are no candidate
> operators accepting the input's native category?

Yes, I think any solution will have to consider the number of possible
conversions for a given mix of function/args.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 17 Apr 2002 15:06:52 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Implicit coercions need to be reined in