On 2000-01-21, Thomas Lockhart mentioned:
> > 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.
> 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?).
Well, rather than creating a huge potential hazard for everyone two weeks
before beta I'm going to settle for a cheaper solution (for now). There
are just too many subtleties that one would have to address early in a
devel cycle, so I'll put that on the the Forget-me-not list for 7.1.
Instead I'd suggest extending the idea of gram.y's xlateSqlType to two
functions provided by the backend
type_sql_to_internal
type_internal_to_sql
which psql and pg_dump could use. Once we switch some or all datatypes
over, this would be the only place we'd need to change -- until it's an
empty function at the end.
Comments? Better ideas?
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden