Re: [HACKERS] Re: inet/cidr/bind
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Re: inet/cidr/bind |
Дата | |
Msg-id | 199810200356.XAA28495@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: inet/cidr/bind (darcy@druid.net (D'Arcy J.M. Cain)) |
Ответы |
Re: [HACKERS] Re: inet/cidr/bind
(Paul A Vixie <paul@vix.com>)
Re: [HACKERS] Re: inet/cidr/bind (darcy@druid.net) Re: [HACKERS] Re: inet/cidr/bind (darcy@druid.net (D'Arcy J.M. Cain)) |
Список | pgsql-hackers |
> However, let's get the two types in right now with two separate groups > of functions and fold them after the release. It won't change the > user interface. Unless we think we can do it quickly. > > In any case, maybe we can add the flag now since we figure we'll need > it later anyway. Once we put entries in the system tables, those really are not going to change dramatically until 6.5. Also, at this point, the least amount of code that can be added, should be added. We already _had_(broken) an inet type, and now we are going to be throwing a lot of duplicate code in there for a new type. There is already concern that we are too close to the 6.4 final date to do anything with the INET type. I am hearing that from another developer. I am not sure what to advise, but adding a new type is not trivial. It is going to require an initdb by everyone, because it is going to be in the regression test. New type is involved, especially if I have to add unique indexing functions and other stuff for the new type. If people really want the INET/CIDR type for 6.4, we are going to need tremendous effort to pull this off. That means good, clean code, documenation, and testing, regression tests, and soon. We can not just throw this in, and we can't expect the entire tree to wait for a new type. My personal opinion is that I am not ready to add a new type, and new duplicate functions for that type, this close to final. I can add the type, and the pg_proc/indexing pointers to link in the existing inet functions, but full type inclusion is too much, I think. For example, I have an inet_ops entry in pg_class. I don't want to add an cidr_ops function that behaves exactly the same. If we can't do this right, then we will not do it for 6.4. My experience is that dumping partial solutions into 250k lines of code is a bad thing. So, if people really want it, it has to be _good_. If is not that important, it can wait. These are my opinions, and of course, can be over-ruled. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: