Re: Range Types - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Range Types
Date
Msg-id 1315903296.7281.107.camel@jdavis
Whole thread Raw
In response to Re: Range Types  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Range Types - typo + NULL string constructor
List 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

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Sponsored development
Next
From: Florian Pflug
Date:
Subject: Re: Patch to improve reliability of postgresql on linux nfs