Re: New cast between inet/cidr and bytea

[Zoltan Boszormenyi <zb(at)cybertec(dot)at>]

Tom Lane írta:
> Zoltan Boszormenyi <zb(at)cybertec(dot)at> writes:
>   
> > Bruce Momjian írta:
> >     
> > > What is the use case for such a cast?
> > >       
>
>   
> > The application doesn't want to parse the textual IP address
> > when all the parsing and checking intelligence is already there
> > in the inet/cidr type checks.
> >     
>
> This presumes exactly the assumption we are questioning, namely that
> there's a universal binary representation for these things.

But there is: network order.

>   There might
> be such for bare IP addresses (ignoring endianness) but the argument
> doesn't scale to CIDR.

Would you enlighten me why not?

>   You've also failed to make the case that this
> application designer has made a sane judgment about whether avoiding
> parsing is a good tradeoff here.
>   

So, reinventing the wheel is always the way to go?
Even when the app is actually storing those IP addresses
with the type and features PostgreSQL provides?

> Also: to the extent that the application is willing to deal with a
> Postgres-specific inet/cidr representation (which, in the end, is
> what this would be) it can do that *today* using binary output format.
> So I'm still not seeing an argument for exposing a cast to bytea.
>
> 			regards, tom lane
>   

But the binary output of inet/cidr needs another round of parsing
which requires using internal server headers.

Would you like a 4/8/16/32 byte output using IP only
or IP + fully represented netmask better?

Best regards,

--
----------------------------------
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/