Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> 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/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
