Re: Implicit coercions need to be reined in

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <thomas(at)fourpalms(dot)org>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Barry Lind <barry(at)xythos(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implicit coercions need to be reined in
Date: 2002-04-17 14:14:34
Message-ID: 6024.1019052874@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <thomas(at)fourpalms(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-04-17 14:15:26 Re: Index Scans become Seq Scans after VACUUM ANALYSE
Previous Message Michael Loftis 2002-04-17 14:11:47 Re: Index Scans become Seq Scans after VACUUM ANALYSE