Re: Why so few built-in range types?

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why so few built-in range types?
Date: 2011-12-02 13:44:50
Message-ID: 20111202134450.GI24234@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
> - ip4 really only stores a single address, not a netmask, not sometimes
> a netmask, or sometimes a range, or sometimes a network and an address,
> or whatever. That really seems like the most common use case, and no
> matter what you do with the other types, some stupid netmask will appear
> in your output when you least expect it.

This is definitely one of the funny complications with our built-in
types. I don't feel that's a feature either. Nor do I consider it
'worse' that we have a type that actually makes sense. :) Regardless of
who developed it, it's simply trying to do too much in one type. I'm
also not convinced that our built-in types even operate in a completely
sensible way when you consider all the interactions you could have
between the different 'types' of that 'type', but I'll admit that I
haven't got examples or illustrations of that- something better exists
and is what I use and encourage others to use.

In some ways, I would say this is akin to our built-in types vs.
PostGIS. My argument isn't about features or capabilities in either
case (though those are valuable too), it's about what's 'right' and
makes sense, to me anyway.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-02 13:56:18 Re: Why so few built-in range types?
Previous Message Peter Geoghegan 2011-12-02 13:33:30 Re: Inlining comparators as a performance optimisation