> What I'd suggest -- and the 7.0 release is certainly one of the better
> times to do this -- is to change the catalog entries to "integer",
> "bigint", etc. and instead do the translation of the "deprecated" (or
> "traditional", if you like) types "int4", "int8", etc. into the standard
> ones. As far as I can see this would require only two changes for each
> datatype (gram.y:xlateSqlType(), and pg_type.h), so this could be done
> transparently to the rest of the code. And client applications don't need
> to know this at all.
> Is there a problem with this I'm not seeing (other than perhaps affective
> attachment to Postgres'isms)? This almost seems too trivial to not have
> been done already.
One reason this hasn't been done is that we would lose the
(occasional) correspondence between internal names and external names,
which isn't a very good reason.
I've also thought that we might implement some "by reference" types to
replace the "by value" types we have now (and use the SQL92 names for
them). But Tom Lane has talked about fixing up the internal problems
we have with passing info about NULLs with "by value" types, so that
might be a bad way to head. However, the downside to eliminating "by
value"s (extra footprint?) might be offset by being able to remove
code which has to handle both cases (extra speed?).
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California