Re: Porting MySQL data types to PostgreSQL - Mailing list pgsql-general

From ptjm@interlog.com (Patrick TJ McPhee)
Subject Re: Porting MySQL data types to PostgreSQL
Date
Msg-id 13b05v56sftdof3@corp.supernews.com
Whole thread Raw
In response to Porting MySQL data types to PostgreSQL  ("Gautam Sampathkumar" <gsampathkumar@gmail.com>)
Responses Re: Porting MySQL data types to PostgreSQL  (Decibel! <decibel@decibel.org>)
List pgsql-general
In article <19363.1185892343@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
% ptjm@interlog.com (Patrick TJ McPhee) writes:
% > One problem with this idea is the treatment of implicit casts between
% > numeric types in TypeCategory(). For implicit casts to work, the type's
% > OID has to be listed in that function (i.e., it has to be a built-in type).
%
% That's not the case.  There probably are some things that won't work
% nicely if TypeCategory() doesn't recognize the type as numeric category,
% but to claim that implicit casts won't work at all is wrong.

I didn't say they won't work at all, but I do say that they won't work
completely. I had to play around with it before I remembered where things
broke down. Suppose you have a type called unsigned, written in C, with an
implicit cast from int4 to unsigned. Then

 SELECT 23::unsigned
 UNION
 SELECT 0;

will work if unsigned has one of the numeric OIDs known to TypeCategory(),
but not if it was defined normally using CREATE TYPE.

You can characterise this as working, just not nicely, but it's still
a problem for anyone trying to implement unsigned, or any other kind of
numeric value, as a user-defined type.

--

Patrick TJ McPhee
North York  Canada
ptjm@interlog.com

pgsql-general by date:

Previous
From: "Paul Linehan"
Date:
Subject: Re: Question about Postgres
Next
From: Thomas Burns
Date:
Subject: pg_restore UTF8 problem