Thread: Re: type conversion discussion

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

Tom Lane writes:

> > 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.

Definitely. But wouldn't three (or six) extra `=' operators be the road of
least resistance or clearest separation? Not sure.

> I doubt that ordinary users touch OIDs at all, and the ones who do
> probably know what they're doing.

Certain elements around these parts actively advocate using oids for keys
or even unsigned numbers (*shudder*). I wouldn't be so sure about this
statement at all.

One thing to keep in mind in any case is that oids might not be int4-like
forever, eventually we might want int8, or the unsigned version thereof.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Peter Eisentraut <peter_e@gmx.net> writes:
>> 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.

> Definitely. But wouldn't three (or six) extra `=' operators be the road of
> least resistance or clearest separation? Not sure.

Actually, that's what we've got now: "oid = 1234" gets parsed into the
oideqint4 operator.  What bugs me about that is the shenanigans the
optimizer has to pull to use an index on the oid column.  I'm hoping
that we can clean up this mess enough so that the operator delivered by
the parser is the same thing the column's index claims to use in the
first place.

> One thing to keep in mind in any case is that oids might not be int4-like
> forever, eventually we might want int8, or the unsigned version thereof.

Agreed, but with any luck that case will work transparently too: the
constant will just get promoted up to int8 before we apply the operator.
        regards, tom lane