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
Re: [HACKERS] Re: inet/cidr/bind
Re: [HACKERS] Re: inet/cidr/bind
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Re: inet/cidr/bind
Следующее
От: Tom
Дата:
Сообщение: Re: [HACKERS] Postgres - Y2K Compliant....Yes or No