Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group