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

Re: Range Types, constructors, and the type system

From: Darren Duncan <darren(at)darrenduncan(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-27 05:29:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> 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.

I'm not saying that you can't use multiple orderings with a data type.  I'm just 
saying that the type only has *at most* one (possibly none) *native* ordering, 
which is what is used when you do something ordered-sensitive with the type, 
such as have a range.

To be specific, if the type system supports a concept like Perl 6 roles (or 
other languages have similar concepts) where types can declare themselves 
members of a union type such as "Ordered", then types of that union would have 
the native ordering and other types wouldn't and then generic range operators 
could be declared over ANYORDERED or such.

>> 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.

Well a related solution is to have exactly 1 text wrapper type which has 2 
attributes, one being the text value and the other being the collation name. 
Then you just have 1 type that does the job instead a separate one per 
collation.  But to keep the semantics, the collation name is part of the 
identity of the type.  For example:

   CREATE TYPE collated_text AS (t text, c collation);

The key point I'm trying to support is that collation issues are firmly attached 
to the text type, not the range type.

Anyway, if a better solution can be arrived at for the problem at hand, then 
good for the team; meanwhile, what I've proposed is the best one I can think of.

-- Darren Duncan

In response to


pgsql-hackers by date

Next:From: Darren DuncanDate: 2011-06-27 06:03:06
Subject: Re: Range Types, constructors, and the type system
Previous:From: Alvaro HerreraDate: 2011-06-27 02:33:06
Subject: Re: pg_upgrade defaulting to port 25432

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