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

Re: Range Types, constructors, and the type system

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Darren Duncan <darren(at)darrenduncan(dot)net>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Range Types, constructors, and the type system
Date: 2011-06-26 15:06:47
Message-ID: 11379.1309100807@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Darren Duncan <darren(at)darrenduncan(dot)net> writes:
> I believe that the best general solution here is for every ordered base type to 
> just have a single total order, which is always used with that type in any 
> generic order-sensitive operation, including any ranges defined over it, or any 
> ORDER BY or any <,>,etc.

We've spent years and blood on making sure that Postgres could support
multiple orderings for any datatype; and there are plenty of natural
examples for the usefulness of that.  So I'm not at all impressed by
any line of reasoning that starts out by baldly throwing that away.

> When we want to have some other "native" ordering for an existing type, such as 
> when we want to use a different text collation, we do this by creating a *new 
> base type*,

Nope.  This has all sorts of problems that you're conveniently ignoring,
beginning with the need to duplicate all of the infrastructure for the
type (such as non-ordering-related operators), and then moving into
difficulties arising from added ambiguity as to which operator is meant.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-06-26 16:16:27
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Previous:From: Markus WannerDate: 2011-06-26 14:12:53
Subject: Re: POSIX question

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