On 2000-01-19, Thomas Lockhart mentioned:
> istm that pg_dump could benefit greatly if it translated internal
> Postgres type names to the SQL92-standard names. For example, int4 ->
> integer, int8 -> bigint, etc. This would be analogous to the
> translation we do when parsing queries in the backend, converting
> (e.g.) integer -> int4.
I certainly think this is a good idea, but I don't consider the proposed
approach too good. The reason is that the next thing you'd have to do is
fix up psql as well, creating one more source of inconsistency. Not to
mention other similar applications which we don't have any control over,
such as pgbash.
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.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
