Re: [HACKERS] Re: inet/cidr/bind

Поиск
Список
Период
Сортировка
От darcy@druid.net
Тема Re: [HACKERS] Re: inet/cidr/bind
Дата
Msg-id m0zVcCx-0000f3C@druid.net
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: inet/cidr/bind  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
Thus spake Bruce Momjian
> > 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.

While I would like everything in there now, I can live with this as long
as the user interface doesn't change.

How about this?  We now have an inet type pretty much completed.  Let's
put that back in right now.  copy all the files involved, substitute
inet to cidr in the function names and make it the new cidr type.  Once
we agree on which one is the host+netmask type add the extra functions
for netmask, masklen, host, network_without_bits, network_with_bits and
broadcast making them stubs if necessary.  I'll get my code into the
right file as soon as possible.  Later we can fold things in better
but we can do it without changing the catalogues.  If it makes it more
efficient we can change the catalogue where 6.5 comes out.

If we can do this right away I think we have a good chance of getting
it into 6.4 properly anyway.

> 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.

Of course this is your decision.  We have the inet type now and as long
as we know what that type is, we can always add the other for 6.5 if
we can't get it in now.

> So, if people really want it, it has to be _good_.  If is not that
> important, it can wait.

So far less than a half dozen people are really involved in this discussion.
How about a quick straw poll of who really wants this in?

> These are my opinions, and of course, can be over-ruled.

Not if you need to do the work on the catalogues they can't.  :-)

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: darcy@druid.net (D'Arcy J.M. Cain)
Дата:
Сообщение: Re: [HACKERS] Re: inet/cidr/bind
Следующее
От: Sferacarta Software
Дата:
Сообщение: using indexes with the OR clause