From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zoltan Boszormenyi <zb(at)cybertec(dot)at> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: New cast between inet/cidr and bytea |
Date: | 2007-05-31 14:08:05 |
Message-ID: | 29065.1180620485@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. There might
be such for bare IP addresses (ignoring endianness) but the argument
doesn't scale to CIDR. 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-31 14:16:41 | Re: Backend crash during explain |
Previous Message | Tom Lane | 2007-05-31 14:01:53 | Re: Attempt to re-archive existing WAL logs after restoring from backup |