Re: Implicit coercions need to be reined in

Started by Zeugswetter Andreas SB SDover 23 years ago9 messages

ZeugswetterA@spardat.at

over 23 years ago

I suspect that the main thing that will cause issues is removal of
implicit coercions to text. For example, in 7.2 and before you can do

test72=# select 'At the tone, the time will be ' || now();
?column?
-------------------------------------------------------------
At the tone, the time will be 2002-04-11 11:49:27.309181-04
(1 row)

I have seen this coding practice extremely often and would be very unhappy if
it were not allowed any more. Imho automatic coercions are a good thing
and should be done where possible. Other extensible databases also allow this
without a cast. Imho the main culprit is finding a "number" format that will not
loose precision when implicitly propagated to.

Andreas

Zeugswetter Andreas SB SD

ZeugswetterA@spardat.at

over 23 years ago

In reply to: Zeugswetter Andreas SB SD (#1)

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

Import Notes

Resolved by subject fallback

Tom Lane

tgl@sss.pgh.pa.us

over 23 years ago

In reply to: Zeugswetter Andreas SB SD (#2)

"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

Thomas Lockhart

thomas@fourpalms.org

over 23 years ago

In reply to: Zeugswetter Andreas SB SD (#2)

...

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

Tom Lane

tgl@sss.pgh.pa.us

over 23 years ago

In reply to: Thomas Lockhart (#4)

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

Thomas Lockhart

thomas@fourpalms.org

over 23 years ago

In reply to: Zeugswetter Andreas SB SD (#2)

...

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

Tom Lane

tgl@sss.pgh.pa.us

over 23 years ago

In reply to: Thomas Lockhart (#6)

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

Thomas Lockhart

thomas@fourpalms.org

over 23 years ago

In reply to: Zeugswetter Andreas SB SD (#2)

...

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

Bruce Momjian

pgman@candle.pha.pa.us

over 23 years ago

In reply to: Tom Lane (#7)

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