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