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
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.
Zoltan Boszormenyi wrote:
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.
Zoltan Boszormenyi wrote:
> Hi,
>
> we at Cybertec have developed cast functions in C between
> inet/cidr <-> bytea for a client and we would like to submit it.
>
> This is how it works:
> - IPv4 inet/cidr value will return 4 bytes if the netmask covers all 32
> bits.
> It returns 5 bytes if t
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> we at Cybertec have developed cast functions in C between
> inet/cidr <-> bytea for a client and we would like to submit it.
Why is this a good idea? Exposing the internal representation of a
datatype is usually bad. What will you do when we add s
Bruce Momjian írta:
Zoltan Boszormenyi wrote:
Hi,
we at Cybertec have developed cast functions in C between
inet/cidr <-> bytea for a client and we would like to submit it.
This is how it works:
- IPv4 inet/cidr value will return 4 bytes if the netmask covers all 32
bits.
It returns 5 b
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
we at Cybertec have developed cast functions in C between
inet/cidr <-> bytea for a client and we would like to submit it.
Why is this a good idea? Exposing the internal representation of a
datatype is usually bad.
I didn
