Tom Lane wrote:
> Bruce Momjian writes:
> > Added to release checklist:
> > * Update inet/cidr data types with newest Bind patches
>
> You should also add "check for zic database updates".
Uh, we already have:
* Update timezone data to match latest zic database (see
src/ti
Tom Lane wrote:
> Paul Vixie <[EMAIL PROTECTED]> writes:
> > i have two suggestions. first, look at the rest of the current source file,
> > in case there are other fixes.
>
> Right, I already grabbed the latest.
>
> > second, track changes this source file during
> > your release engineering pr
Bruce Momjian writes:
> Added to release checklist:
> * Update inet/cidr data types with newest Bind patches
You should also add "check for zic database updates".
regards, tom lane
---(end of broadcast)---
TIP 9: the
; ((dst - odst) * 8)) {
re:
> To: Steve Atkins <[EMAIL PROTECTED]>
> Cc: pgsql-hackers , [EMAIL PROTECTED]
> Subject: Re: [HACKERS] [BUGS] Bug in create operator and/or initdb
> Comments: In-reply-to Steve Atkins <[EMAIL PROTECTED]>
> message dated "Mon,
> We didn't really want to assume that all platforms are using libbind :-(
i think you could have, at the time, since windows wasn't even a gleam in
pgsql's eye. even now, libbind would be a dependable universal dependency,
since we publish windows binaries.
> > the pgsql "fork" of this code did
Paul Vixie <[EMAIL PROTECTED]> writes:
> i have two suggestions. first, look at the rest of the current source file,
> in case there are other fixes.
Right, I already grabbed the latest.
> second, track changes this source file during
> your release engineering process for each new pgsql version
On Mon, Jan 31, 2005 at 12:16:26PM -0500, Tom Lane wrote:
> Steve Atkins <[EMAIL PROTECTED]> writes:
> > The cidr type, including it's external interface, is simply broken.
>
> That is a large claim that I don't think you have demonstrated.
> The only one of your examples that seems to me to contr
Tom Lane <[EMAIL PROTECTED]> writes:
> steve=# select '224.0.0.0'::cidr;
> cidr
> -
>224.0.0.0/4
>
> which should be /32 according to what the docs say:
224-239 are multicast addresses. Making it /4 makes the entire multicast
address space one network block which is
Paul Vixie <[EMAIL PROTECTED]> writes:
> when my cidr datatype was integrated into pgsql, the decision was made to
> incorporate a copy of bind's inet_net_pton.c rather than add a link-time
> dependence to libbind.a (libbind.so).
We didn't really want to assume that all platforms are using libbind
Steve Atkins <[EMAIL PROTECTED]> writes:
> The cidr type, including it's external interface, is simply broken.
That is a large claim that I don't think you have demonstrated.
The only one of your examples that seems to me to contradict the
documentation is this one:
steve=# select '224.0.0.0'::c
On Sun, Jan 30, 2005 at 09:49:43PM -0600, Larry Rosenman wrote:
> On Sun, 30 Jan 2005, Tom Lane wrote:
>
> >Steve Atkins <[EMAIL PROTECTED]> writes:
> >>For a replacement type, how important is it that it be completely
> >>compatible with the existing inet/cidr types? Is anyone actually using
> >>
On Sun, 30 Jan 2005, Tom Lane wrote:
Steve Atkins <[EMAIL PROTECTED]> writes:
For a replacement type, how important is it that it be completely
compatible with the existing inet/cidr types? Is anyone actually using
inet types with a non-cidr mask?
If you check the archives you'll discover that our
> Note also that the btree optimization for << depends on having a
> plan-time-constant righthand side; so it's useless for joins, for
> instance. I didn't look closely, but I'd suppose that rtree could
> help for << searches without that constraint.
Indeed it can... tho rtree seems to be unable
John Hansen <[EMAIL PROTECTED]> writes:
>> On the contrary I'm using it for something that isn't really what it was
>> designed for precisely *because* of the index methods. What index access
>> methods are you looking for that are lacking?
>>
>> db=> explain select * from foo where foo_code << '4
> On the contrary I'm using it for something that isn't really what it was
> designed for precisely *because* of the index methods. What index access
> methods are you looking for that are lacking?
>
> db=> explain select * from foo where foo_code << '4.0.0.0/8';
explain select * from foo where f
"John Hansen" <[EMAIL PROTECTED]> writes:
> I wouldn't think so, anyone I've spoken with has come up with other ways of
> managing that kind of info, because of, as you mentioned, it's lack of
> proper index methods.
On the contrary I'm using it for something that isn't really what it was
design
> I suspect that the right thing to do is to kill the inet type
> entirely, and replace it with a special case of cidr. (And
> possibly then to kill cidr and replace it with something that
> can be indexed more effectively.)
Yes, which is actually what brought this to my attention.
I'll be send
Steve Atkins <[EMAIL PROTECTED]> writes:
> For a replacement type, how important is it that it be completely
> compatible with the existing inet/cidr types? Is anyone actually using
> inet types with a non-cidr mask?
If you check the archives you'll discover that our current inet/cidr
types were l
On Sat, Jan 29, 2005 at 10:07:30PM -0500, Tom Lane wrote:
> "John Hansen" <[EMAIL PROTECTED]> writes:
> > In that case may I suggest fixing the catalog so network_* functions exists
> > for both datatypes!
>
> Redesigning the inet/cidr distinction is on the to-do list (though I'm
> afraid not ver
"John Hansen" <[EMAIL PROTECTED]> writes:
> In that case may I suggest fixing the catalog so network_* functions exists
> for both datatypes!
Redesigning the inet/cidr distinction is on the to-do list (though I'm
afraid not very high on the list). ISTM it should either be one type
with a disting
"John Hansen" <[EMAIL PROTECTED]> writes:
> CREATE FUNCTION my_func (inet, inet) as '$libdir/my_func.so' LANGUAGE 'C'
> IMMUTABLE STRICT;
> CREATE OPERATOR <<< (
> PROCEDURE = my_func,
> LEFTARG = cidr,
> RIGHTARG = cidr,
> RESTRICT = contsel,
> JOIN = contjoinsel
> )
> My opinion is that this is a very bogus shortcut in the
> network datatype code. There are no cases outside the
> inet/cidr group where an operator doesn't exactly match its
> underlying function. (The whole business of inet and cidr
> being almost but not quite the same type is maldesigned
22 matches
Mail list logo
