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

Re: Range Types

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Range Types
Date: 2011-09-01 07:32:25
Message-ID: 1314862345.7281.26.camel@jdavis (view raw or flat)
Thread:
Lists: pgsql-hackers
Updated patch attached.

Changes:

1. Now supports new constructor scheme. If you define a range foorange,
you get the following constructors:
 * foorange() -- produces empty foorange
 * foorange(S) -- produces singleton range [S]
 * foorange(L,B) -- produces range [L,B)
 * foorange(L,B,'(]') -- produces range (L,B]

Actually, the two-argument form uses a special "default_flags" that can
be specified at creation time, and that defaults to '[)'.

The way I accomplish this is by generating 4 functions at definition
time -- a little ugly, and I am open to suggestions. I ran into a
problem using the default argument as Robert suggested because
pg_node_tree doesn't have a working input function (intentionally so),
so I couldn't get the built-in range types to work with initdb. The
constructors all essentially point to the same C function, aside from
some indirection that I did to avoid excessive complaining from the
opr_sanity test. Again, suggestions welcome.

2. Documentation has been updated.

3. Now there's support for multiple range types over a single base type,
e.g. two text ranges using different collations.

TODO:

There is still some cleanup to do, e.g. pg_dump. I'd like to get some
feedback to stabilize the user-facing behavior before I put too much
effort into the code cleanup (which shouldn't take long, but I just
don't want to work toward a moving target).

Regards,
	Jeff Davis

Attachment: rangetypes-20110831.gz
Description: application/x-gzip (41.9 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2011-09-01 08:13:32
Subject: help with plug-in function for additional (partition/shard) visibility checks
Previous:From: hubert depesz lubaczewskiDate: 2011-09-01 06:05:51
Subject: Re: [GENERAL] pg_upgrade problem

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