Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> I think your plan looks good for the numerical land. (I'll ponder the oid
> issues in a second.) For other type categories, perhaps not. Should a line
> be promoted to a polygon so you can check if it contains a point? Or a
> polygon to a box? Higher dimensions? :-)
Line->polygon, probably not. On the other hand I can certainly imagine
that box->polygon would be a reasonable promotion. The point of the
proposal is to make these choices table-driven, in any event; so they'd
be fairly easy to change if someone didn't like them.
> [ enumerates cases where casting is needed ]
> e) The function is overloaded for many types, amongst which is text. Then
> call the text version. I believe this would currently fail, which I'd
> consider a deficiency.
This seems to be the only case that's really worth debating. Is it
better to fail (drawing attention to the ambiguity) than to make a
default assumption? I tend to agree that we want a default, but
reasonable people might disagree.
> The fact that an oid is also a number should be an implementation detail.
Could be. A version or three ago you actually did have to write
... where oid = 1234::oid
if you wanted to refer to a specific row by OID. However, while it
might be logically purer to insist that OIDs are not numbers, it's just
too damn handy to be laxer about the distinction. I've used both the
old and new behavior and I much prefer the new. If you want an actual
argument for it: I doubt that ordinary users touch OIDs at all, and
the ones who do probably know what they're doing. You might see some
inconsistency between my position on OIDs and my position on booleans
(where I *don't* want cast-free conversions), but I draw the distinction
from experience about what sorts of operations are useful and how many
real-life errors can be caught by hard-line error checks.
regards, tom lane
