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-13 08:41:36
Message-ID: 1315903296.7281.107.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Another updated patch is attached.

Changes:

* support for send/recv
* significant cleanup and fixes
* test improvements

TODO:

* pg_dump support. This requires outputting collation names and
opclass names (because those are part of the range type definition).
Currently, that's only done for indexes through special functions in
ruleutils.c. Should I define such functions there as well, or is there a
simpler approach? Also, I have to filter out the generated constructor
functions because those are created internally when defining a new range
type.
* some error messages should be improved
* Originally, I wasn't sure whether to define a RangeCoerceExpr
(similar to ArrayCoerceExpr), because the only use I had was for typmod.
But that is necessary for casts as well, so I'll go ahead and do that
and we'll get both casts and typmod for range types.
* I think I should avoid some syscache lookups for some of the generic
range functions. Right now they are done for every invocation, but it
would be pretty simple to avoid lookups when looking up the same range
type as last time.

Review questions:

* Do we like the new constructor behavior from the users' standpoint?
* Right now, the patch accomplishes that behavior by generating
several constructor functions every time a new range type is defined. Is
that acceptable? Is there a better way?

Regards,
Jeff Davis

Attachment Content-Type Size
rangetypes-20110912.gz application/x-gzip 46.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-09-13 11:07:42 Re: Patch to improve reliability of postgresql on linux nfs
Previous Message Simon Riggs 2011-09-13 08:36:26 Re: Sponsored development