Persistent PostgreSQL: support for "inet" column

[rekado]

Hi list,

I currently writing a frontend for an existing PostgreSQL database
that uses the "inet" column to store IP addresses and networks.
Persistent's PostgreSQL backend currently doesn't support this column
type, probably in part because there are no conversion functions for
this column type in postgresql-simple.

As the "inet" column type can contain IPv4 and IPv6 addresses as well
as networks there is no simple one-to-one mapping from column type to
Haskell type (there is Data.IP and Data.Network.Address for the
possible types, though).

I'd like to write a patch to add support for this column, but I don't
know what the prefered way to do this would be in this situation.
Should Persistent simply return a ByteString and leave the conversion
task up to the application (ugly)? Or should I specify four new column
types (IPv4 address, IPv6 address, IPv4 network, IPv6 network) in the
hope that the column is used only for one type of thing in existing
databases?

Or is there a generic type that I have overlooked that would give me a
simple ByteString without any further modifications?


-- rekado

[Michael Snoyman]

I don't think I really know enough about how PostgreSQL stores this
data, or how libpq delivers that data to the application, to give an
intelligent answer. A ByteString (or a newtype around one) could be an
appropriate solution, as could a sum type. But it really depends on
details that I'm not familiar with.

Michael

[Felipe Almeida Lessa]

I'm afraid I don't have anything else to say besides commenting that you need to take PersistValue limitations into consideration as well.

Cheers,

--
Felipe – enviado do meu Galaxy Tab.

[Ricardo Wurmus]

On 30 May 2012 04:49, Felipe Almeida Lessa <felipe...@gmail.com> wrote:
> I'm afraid I don't have anything else to say besides commenting that you
> need to take PersistValue limitations into consideration as well.

What limitations of PersistValue are you referring to? Isn't it a mere
wrapper around a Haskell data type that should store a marshalled cell
value?

> Em 29/05/2012 14:55, "Michael Snoyman" <mic...@snoyman.com> escreveu:
>> I don't think I really know enough about how PostgreSQL stores this
>> data, or how libpq delivers that data to the application, to give an
>> intelligent answer. A ByteString (or a newtype around one) could be an
>> appropriate solution, as could a sum type. But it really depends on
>> details that I'm not familiar with.

According to inet.h (see
http://doxygen.postgresql.org/structinet.html), the format that
PostgreSQL uses internally for the inet type is this:

typedef struct
{
       unsigned char family;           /* PGSQL_AF_INET or PGSQL_AF_INET6 */
       unsigned char bits;                     /* number of bits in netmask */
       unsigned char ipaddr[16];       /* up to 128 bits of address */
} inet_struct;

typedef struct
{
       char            vl_len_[4];
       inet_struct inet_data;
} inet;

Would it be acceptable to declare a Haskell type just like the
inet_data struct and let applications convert it to their desired
representation as they see fit?

E.g.

  data InetFamily = Inet4 | Inet6
  data Inet = InetFamily Int [Word16]

I'm not sure where something like that would need to be added. I guess
we'd need to have instance declarations in postgresql-simple first.

(Note: I could be totally wrong.)

[Felipe Almeida Lessa]

On Wed, May 30, 2012 at 10:26 AM, Ricardo Wurmus
<ricardo...@gmail.com> wrote:
> On 30 May 2012 04:49, Felipe Almeida Lessa <felipe...@gmail.com> wrote:
>> I'm afraid I don't have anything else to say besides commenting that you
>> need to take PersistValue limitations into consideration as well.
>
> What limitations of PersistValue are you referring to? Isn't it a mere
> wrapper around a Haskell data type that should store a marshalled cell
> value?

Yes, but as it is a simple Haskell data type it is quite limited to
what kinds of values it may store. It certainly does not currently
include a constructor for Inet values, and I'm not sure how/if we may
add them (that's a question only Michael or Greg may answer). What
I'm trying to say is that going through the ByteString route may be
easier just because there will be a lot less infrastructure to be
touched, so take that into account =).

Cheers,

[1] https://github.com/yesodweb/persistent/blob/master/persistent/Database/Persist/Store.hs#L125

--
Felipe.

[Hugo Gomes]

I wanted to do the same for the postgresql ltree extension:

http://www.postgresql.org/docs/current/static/ltree.html

Perhaps its easier to map to a haskell tree datatype than with the inet column (i hope)

2012/5/30 Felipe Almeida Lessa <felipe...@gmail.com>