Re: [HACKERS] Data type removal
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Data type removal |
Дата | |
Msg-id | 3518B524.77BFDA85@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Data type removal (dg@illustra.com (David Gould)) |
Ответы |
Re: [HACKERS] Data type removal
Re: [HACKERS] Data type removal |
Список | pgsql-hackers |
> The postgres type system is very flexible and powerful as is. What is > the problem this is trying to solve? > > What is the motivation for data type removal? There are many motivations involved here. I brought it up originally because the char2-16 types are not supported and do not provide any functionality over the char(),varchar(),text string types. Others suggested that since they do not care about the geometric types that those should be removed too. I regret bringing it up. Postgres has many unique features, and stripping it to become a plain vanilla SQL92 machine is a waste of time imo. If any restructuring happens which removes, or makes optional, some of the fundamental types, it should be accomplished so that the types can be added in transparently, from a single set of source code, during build time or after. OIDs would have to be assigned, presumably, and the hardcoding of the function lookups for builtin types must somehow be done incrementally. Probably needs more than this to be done right, and without careful planning and implementation we will be taking a big step backwards. With the amount of time being spent in discussion, _still without any quantitative estimates for performance improvement_, it seems like someone should do some measurements. Even without them though it is pretty clear that it won't benefit a large database, since the fraction of time spent constructing a query will be small compared to the time it takes to traverse the tables in the query. Seems to me that Postgres' niche is at the high end of size and capability, not at the lightweight end competing for design wins against systems which don't even have transactions. - Tom
В списке pgsql-hackers по дате отправления: