Re: [HACKERS] Re: Status on 7.0
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Re: Status on 7.0 |
Дата | |
Msg-id | Pine.LNX.4.21.0001201506290.349-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Status on 7.0 (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Ответы |
Re: [HACKERS] Re: Status on 7.0
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: