Bruce Momjian writes:
> Is it only implicit casts you are worried about? Do we have any of
> those left? All functions that take cidr also have an inet version, so
> I don't see how an implicit cast to cidr could happen.
The cast to cidr isn't implicit anymore anyway. What I currently have
it
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > I agree. Let's do the zeroing and see if people complain about it.
>
> I'm complaining. Losing data on a cast is not common behavior.
[ Sorry for the delay.]
OK, that's clear. :-)
I looked around to see if I could find any places where we im
Bruce Momjian wrote:
> I agree. Let's do the zeroing and see if people complain about it.
I'm complaining. Losing data on a cast is not common behavior.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 9:
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Without the flag, it's okay for cidr-to-inet to be a
> >> binary-compatible (no function) conversion. However, inet-to-cidr
> >> has to either zero out bits to the right of the netmask, or error out
> >> if any
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Without the flag, it's okay for cidr-to-inet to be a
>> binary-compatible (no function) conversion. However, inet-to-cidr
>> has to either zero out bits to the right of the netmask, or error out
>> if any are set. Joachim Wieland p
Tom Lane wrote:
> Without the flag, it's okay for cidr-to-inet to be a
> binary-compatible (no function) conversion. However, inet-to-cidr
> has to either zero out bits to the right of the netmask, or error out
> if any are set. Joachim Wieland posted a patch that makes the
> coercion function ju
On Jan 25, 2006, at 9:29 AM, Bruce Momjian wrote:
Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
I wonder if this would be an opportunity to fix Postgres's
handling of
addresses like '10.1'.
You've mistaken this for a proposal to change the I/O behavior, which
it is specifically n
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> The spec is quite explicit that inet_pton is not expected to accept the
> abbreviated forms or any non-decimal values.
Hum. That distinctly doesn't match my memory but it seems you're right. The
spec mandates inet_ntoa and inet_addr support it but
On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> I've reported the bug in the one instance I've found.
> What have you found with this omission?
>
> It would be passing strange since most software just passes the text to
> inet_aton or inet_pton.
STANDARDS
The inet_ntop() and inet_pton
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> > This isn't an obscure old-fashioned thing. People really do use this syntax.
>
> Given how little code now supports 10.1 meaning 10.0.0.1, that seems a
> questionable point.
I've reported t
On Wed, Jan 25, 2006 at 06:30:47PM - I heard the voice of
Andrew - Supernews, and lo! it spake thus:
> On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> > This isn't an obscure old-fashioned thing. People really do use
> > this syntax.
>
> Given how little code now supports 10.1 meaning 1
Greg Stark <[EMAIL PROTECTED]> writes:
> If we could store inet in four bytes it would be vastly more efficient both in
> disk space usage and in cpu at runtime.
You forgot IPv6.
regards, tom lane
---(end of broadcast)---
TI
"Larry Rosenman" writes:
> We had a **LONG** discussion on the I/O formats back in the 7.2 timeframe.
> the current
> behavior is the result of that.
Well I wasn't around for 7.2 but I was for a discussion around 7.3, maybe it's
the same one. Regardless, back then there was an implied assumptio
On Jan 25, 2006, at 10:30 AM, Andrew - Supernews wrote:
On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
This isn't an obscure old-fashioned thing. People really do use
this syntax.
Given how little code now supports 10.1 meaning 10.0.0.1, that seems a
questionable point.
All code th
On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> I have a question in a different direction. What is the meaning of the
> network mask in the inet data type anyways? Hosts don't have network masks,
> only networks.
As far as I can tell, the "inet" semantics are supposed to represent a
networ
* Greg Stark ([EMAIL PROTECTED]) wrote:
> I have a question in a different direction. What is the meaning of the network
> mask in the inet data type anyways? Hosts don't have network masks, only
> networks.
>
> If we could store inet in four bytes it would be vastly more efficient both in
> disk
On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> This isn't an obscure old-fashioned thing. People really do use this syntax.
Given how little code now supports 10.1 meaning 10.0.0.1, that seems a
questionable point.
>> Indeed so. However the current behaviour has neither the merit of being
I have a question in a different direction. What is the meaning of the network
mask in the inet data type anyways? Hosts don't have network masks, only
networks.
If we could store inet in four bytes it would be vastly more efficient both in
disk space usage and in cpu at runtime.
I think it woul
On 2006-01-25, Bruce Momjian wrote:
> Andrew - Supernews wrote:
>> Having the behaviour be dependent on which part of the IP space is used
>> is a total nonsense on the modern, CIDR, internet! The C in CIDR even
>> stands for "Classless", so how can you ever justify introducing _new_,
>> non-tradi
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2006-01-25, Bruce Momjian wrote:
> > Agreed. 10.1 as 10.0.0.1 is an old behavior which has been removed from
> > most modern versions of networking tools.
On the contrary not only is it still widely used but it is *required* by POSIX
for the
Andrew - Supernews wrote:
> On 2006-01-25, Bruce Momjian wrote:
> > Agreed. 10.1 as 10.0.0.1 is an old behavior which has been removed from
> > most modern versions of networking tools.
>
> Indeed so. However the current behaviour has neither the merit of being
> traditional nor the merit of bei
On 2006-01-25, Bruce Momjian wrote:
> Agreed. 10.1 as 10.0.0.1 is an old behavior which has been removed from
> most modern versions of networking tools.
Indeed so. However the current behaviour has neither the merit of being
traditional nor the merit of being logical:
=> select '10.1'::cidr;
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > I wonder if this would be an opportunity to fix Postgres's handling of
> > addresses like '10.1'.
>
> You've mistaken this for a proposal to change the I/O behavior, which
> it is specifically not.
>
> > The standard interpretation of t
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
>> I wonder if this would be an opportunity to fix Postgres's handling
>> of addresses like '10.1'.
>
> You've mistaken this for a proposal to change the I/O behavior, which
> it is specifically not.
>
>> The standard interpretation of this
Greg Stark <[EMAIL PROTECTED]> writes:
> I wonder if this would be an opportunity to fix Postgres's handling of
> addresses like '10.1'.
You've mistaken this for a proposal to change the I/O behavior, which
it is specifically not.
> The standard interpretation of this is the same as '10.0.0.1'.
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> If inet-to-cidr can zero out bits silently, then wouldn't making it an
> assignment cast be rather dangerous and error-prone?
The proposal was to make cidr-to-inet an implicit cast (happens automatically
without being requested) but make cidr-to-i
This is exactly what I had in mind:
split the types
zero out the bits going to cidr
no change going to inet
make functions take inet, which as not cast change
---
Tom Lane wrote:
> We've had
On 2006-01-24, Tom Lane <[EMAIL PROTECTED]> wrote:
> Without the flag, it's okay for cidr-to-inet to be a binary-compatible (no
> function) conversion. However, inet-to-cidr has to either zero out bits
> to the right of the netmask, or error out if any are set. Joachim Wieland
> posted a patch th
On Tue, Jan 24, 2006 at 01:23:17PM -0500, Tom Lane wrote:
> Without the flag, it's okay for cidr-to-inet to be a binary-compatible (no
> function) conversion. However, inet-to-cidr has to either zero out bits
> to the right of the netmask, or error out if any are set. Joachim Wieland
> posted a
29 matches
Mail list logo
