Re: Refactoring the Type System
От | Andrew Dunstan |
---|---|
Тема | Re: Refactoring the Type System |
Дата | |
Msg-id | 4CDDE9FB.1030004@dunslane.net обсуждение исходный текст |
Ответ на | Re: Refactoring the Type System (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
On 11/12/2010 07:07 PM, Jeff Davis wrote: > On Fri, 2010-11-12 at 08:34 -0800, David Fetter wrote: >> Folks, >> >> For the past couple of years, I've been hearing from the PostGIS >> people among others that our type system just isn't flexible enough >> for their needs. It's really starting to show its age, or possibly >> design compromises that seemed reasonable a decade or more ago, but >> are less so now. >> >> To that end, I've put up a page on the wiki that includes a list of >> issues to be addressed. It's intended to be changed, possibly >> completely. >> >> http://wiki.postgresql.org/wiki/Refactor_Type_System >> >> What might the next version of the type system look like? > This problems (as stated) strikes me as pretty overwhelming. > > 1. As far as I can tell, we have the best type system of any SQL DBMS. > 2. Getting a type system right is a hard problem by itself, and there > isn't any obvious consensus (although I think there is some agreement on > some issues). > 3. Type systems are more challenging for a DBMS because you need to > account for things like storage, indexing, and optimization in ways that > programming languages don't (consider: when comparing an int4 and an > int8, you may want to coerce based on what indexes you have available). > 4. SQL standard issues. In particular, I think that any modern type > system will run into pretty severe problems with NULLs in one way or > another. I think we'd have to pay very close attention to the standard > when designing a new type system, because I suspect that retrofitting > the standard onto a system we invent independently would be a disaster. > 5. Backwards compatibility issues. > > I think the best we'll do is be able to hack on some of the things that > we actively want and have clear use cases for, such as type interfaces. > We might have to give up on some of the more ambitious ideas that > involve propagating interesting information through the type inference > system; or having any real type that wasn't declared with CREATE TYPE. > Consider that right now we bundle the element type information along > with the array _value_. Yeah, composites too, IIRC. It's a bit sad. But those are really just warts show the difficulties we face in implementing types. I'm still waiting for some seriously different yet possible thing we could do. (And I agree we do have about the best type system around). cheers andrew
В списке pgsql-hackers по дате отправления: