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:52:27
Message-ID: 6368.1019055147@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:
>> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-04-17 14:55:36 Re: Index Scans become Seq Scans after VACUUM ANALYSE
Previous Message Thomas Lockhart 2002-04-17 14:42:52 Re: Implicit coercions need to be reined in